Auto-upgrading players JVMs

General Discussions
#1

By auto-generating all the JNLPs on the fly (which is what the new JGF is doing), we open up some interesting new possibilities for features.

One of these is to automatically insert a requirement for the VERY latest JVM, right down to the smallest _xx number, thereby keeping people automatically at the latest version.

Even now, I quite often see people with 1.4.1_xx installed - even though I know that release is riddled with critical bugs.

The auto-updater supplied by Sun ONLY exists on windows, and doesn’t work as one might expect, positively refusing to download (or even notify!) on _xx releases, even though these are the MOST IMORTANT to auto-download.

There is no auto-updated for linux etc.

So…this poll.

#2

To clarify, the options (as I see them - other suggestions welcome) are:

  • update within the major version only, i.e. if you have 1.4 you will be upgraded to the latest 1.4.x_y, but NOT to 1.5.x_y

  • update within the minor version only, i.e. if you have 1.4.1 you will be upgraded to the latest 1.4.1_y only but NOT to 1.4.2. This might be the “safest”, “least intrusive”, but c.f. previous comments - if there is a later .X version, with Sun JVM’s you need it!

  • just force everyone to the latest of everything, i.e. force everyone to java 5. Included for completeness :slight_smile:

NB: I am aware that there are reasons why people don’t want to - or mustn’t! or even can’t - upgrade at all. E.g. if a company has standardized on a particular JVM version across the board. I remember that some here (crystalsquid?) regularly have multiple parallel versions installed in order to test with each, and as I understand it it’s quite easy IF you really need to do it. So perhaps that’s not an issue, because those with this need probably need to know how to manage the multiple JVM’s already?

#3

And if your answer is “no” please explain why.

It is not obvious to me why none of the above would be desirable.

As an author, I’m aiming always to enforce the latest version within the major version upon the players because it drastically reduces the amount of time I spend supporting people who have bugs that I’m unable to reproduce because they are entirely down to having an outdated version.

If webstart had a “version: 1.4.LATEST” I would use it as an author. JGF’s auto-generation provides the possibility of doing this where Webstart natively does not.

#4

[quote]And if your answer is “no” please explain why.

It is not obvious to me why none of the above would be desirable.

As an author, I’m aiming always to enforce the latest version within the major version upon the players because it drastically reduces the amount of time I spend supporting people who have bugs that I’m unable to reproduce because they are entirely down to having an outdated version.

If webstart had a “version: 1.4.LATEST” I would use it as an author. JGF’s auto-generation provides the possibility of doing this where Webstart natively does not.
[/quote]
The problem with auto-updating is that sometimes new bugs are introduced. What if Java gets ahead of your development?

For example at the company I work for, one of the QA testers got an update that no one else had had from the Java auto-updater (I can’t remmber which one, was several months ago), but all of a sudden this one person was having errors no one else had. We realized later she had the auto-updater on and days had been wasted looking at code that had nothing wrong with it. It was a bug introduced in the version she obtained.

The point here is that not all revisions are fixing bugs, they are some times (almost always), creating new ones as well. Not just in Java, in any software.

Even if the new version is fine for your program, the user may have other programs that now behave wrong. That happened with one of our companies major customers. We had to figure out how to let them run both versions of Java (at our expense) and get someone to configure them, because we forced them to upgrade to the version we were at. The software they were using was developed by contractors so their was no newer version available that was compatible.

As the old IT saying goes: Newer doesn’t guarantee better, just less tested.

#5

Well, for instance, no version of 1.4 is generally safely usable prior to 1.4.2_04 because of the vast numbers of bugs being fixed. I would refuse to support anyone’s bugs on anything prior to that - especially seeing as the JVM won’t even work properly with SSL or HTTPS unless you manually import the certs that expired during _03 :).

I’ve heard of some _05 and _06 new/regression bugs, presumably they were being less diligent because 5 was going out the door?

Perhaps…choose a “JGF preferred” JVM (human choice, updated periodically), such as 1.4.2_04 at the moment, on the grounds that it’s the best compromise, and make that the default unless any particular author chooses to manually accept an earlier version (or demand a later one) ?

#6

Wouldn’t that make the user download that specific version even though they have a later 1.4.2 or even 5?

  • elias
#7

I re-read the webstart SDK docs a week ago, and my understanding was that you can specify “+” with _xx releases.

The only special thing is that if you specify _xx release you have to provide a URL to download that release (wherease with e.g. 1.4+ it is optional whether to specify a URL).