VStar not starting on Windows10 after Java update

Affiliation
American Association of Variable Star Observers (AAVSO)
Fri, 12/14/2018 - 15:45

Hi all,

I am unable to use VStar in my Windows 10 machine after Java environment v8 update 191 was installed yesterday.
A pop-up window asking to insert a USB disk comes up every time I try to run the program via WebStart.
I can't close that window, the Java Web launcher is working without success.

Have any of you had a similar problem? Maybe some incompatibility with this latest Java update?

Cheers,
Sebastian

Affiliation
American Association of Variable Star Observers (AAVSO)
VStar not starting on Windows10 after Java update

Hi Sebastian,

I am using Win10 and Java v8 update 191 and everithing works fine (see the screenshot). No idea whаt nappened with your VStar.

Regards,

Velimir

File upload
Affiliation
American Association of Variable Star Observers (AAVSO)
Is there a rewrite for VSTAR or an "online" version?

Vstar won't work on Safari 12. Java is enabled in preferences/security.

I needed to update Vstar anyway, so I did.

No luck. A search found this:

"The latest versions of Safari, Firefox and Chrome have all dropped support for Java. It's a massive online security risk and always has been. Flash is next on the list. Can't remember the exact date, but Adobe is dropping all support and development for it soon. HTML5 can play video on its own. It needs no help from a Flash or Shockwave plugin."

If Java is no loger viable, how is Vstar working now-days?

Is there an "online" version that I didn't see on the vstar webpage?

RayTRE

Affiliation
Astronomical Society of South Australia (ASSAU)
On re-writes, online version, Java

Hi RayTRE

You can download a non-WebStart Java archive from here:

  SourceForge VStar download page

VStar has always been a desktop application, even when downloaded via WebStart. The latter imposes more constraints on what the application can do on your system, but that's less important than you might think, since it's a desktop application after all. 

At some point, the WebStart (JNLP) version will go away.

The question of whether Java is still viable is a separate one.

Other than oft-cited security concerns, Oracle appears to be complicating Java's future usage. Luckily, others are stepping in to mitigate this (e.g. see https://aws.amazon.com/corretto/). I'm still sorting out what the future looks like with respect to Java. Other than Java, as a software engineer I split my time between use of Python, R, C/C++, Fortran (yes) while exploring newer languages like Rust and Julia.

There is no online version rewrite (e.g. web application) planned, at least not by me, although it was considered at one point.

If there is ever a VStar rewrite of any sort in future, Java wouldn't be the language I'd choose, not because I think it's a bad language but largely because there are other options for new development.

Python and R have their merits and would be high on the list.

In the meantime, myself and others plan to continue slowly adding features and fixing bugs to VStar as time permits.

David

Affiliation
American Association of Variable Star Observers (AAVSO)
Python vs R for this purpose

quote: Python and R have their merits and would be high on the list.

Worthy choices; I've spent years with each. But between the two, there can be little remaining doubt that python dominates R for purposes like this one:

  • Python has automated unit-testing facilities; R has ~ none.
  • Python is a standard language for web pages; R doesn't really support web functions.
  • Python now has excellent astronomy support, due largely to STSci's standardization on it and the resulting astropy code library.

R has statistical elegance, but python has testability and lots of pre-written. pre-tested astro code available. Last year I ported my thousands of lines of R code to python. The investment was worth it.

And, yes, someday Java probably has to go.

Affiliation
Astronomical Society of South Australia (ASSAU)
And yet...

Hi Eric

In reply to each point:

  • Python has automated unit-testing facilities; R has ~ none.
  • Python is a standard language for web pages; R doesn't really support web functions.
  • Python now has excellent astronomy support, due largely to STSci's standardization on it and the resulting astropy code library.
  • Python has automated unit-testing facilities; R has ~ none.
    • There's RUnit, test_that, RSelenium. They do have to be installed, like many R libraries.
    • If you mean that Python has unittest as an inbuilt library, then sure, but there are plenty of others to choose from such as pytest along with plugins such as hypothesis.
  • Python is a standard language for web pages; R doesn't really support web functions.
    • Reactive web apps with Shiny in R is a mature approach.
    • Sure, Python has django, Flask, Bokeh, Dash (somewhat like Shiny for Python, but not as mature).
  • Python now has excellent astronomy support, due largely to STSci's standardization on it and the resulting astropy code library.
    • I suspect you're right and that there are many more Python libraries than for R, especially as you say, like astropy. There certainly are CRAN astronomy libraries for R though. I have more experience with the Python libs to be able to say more at this point however.

My view of Python and R and every other programming language is that they are tools, more appropriate for some things than others. None is without flaws. I don't always get to choose which language to use. Sometimes a reasonable answer is to use both (e.g. R Shiny web app talking to Python code via the R reticulate library).

I don't actually think there's much in it between R and Python in the general case.

However, I do think it's good for a group in some domain to standardise on one language to reduce confusion and to push ahead with functionality rather than getting bogged down in debate. If Python is deemed more appropriate by concensus or sometimes, as may be necessary, by decree for AAVSO development in future, that's fine.

As you say, Java probably has to go someday. It seems a perrenial problem problem in software development that we are always faced with the rise and fall of programming languages. I doubt that any language is ultimately immune, but legacy code bases sometimes make the demise of a language less than inevtiable.

David