Backwards compatibility and auto updates

[Richard Bair]

> Co-bundling the jre in my app is overkill (and now I'd have to worry about OS versions, 32bit/64bit etc).

Apple's universal binary is genius :-). But really you can just do 32-bit if that's what you want. Or offer both, or co-bundle both and switch on the fly.

> I've never had a problem with backwards compatibility of jre's except for that one when they did that big Swing change (around 1.5, I think), which caused exactly the sort of problems I'm worried about. My GUI started looking different overnight. Swing changes had to be few and far between and the platform stagnated. 

You've been lucky :-)

> There are also many great features from Webstart that are lost if I can't use it (version updates, detecting the host server, OS detection for native libraries, etc). Seems self-defeating to be losing all the good deployment features when the whole point of the tight jre integration is to make deployment easier. 
> 
> And, thinking bigger than my own use case, anyone wanting to deploy as an applet (the most supported deployment option), won't be  able to control the jfx version. Even if they limit themselves to a specific jre, the jfx version within that jre will be the latest in the current toolset. 

Actually no, the applet case is special. There are security vulnerabilities in the applet that get fixed regularly as they are discovered. This is unique to the applet in that a security vulnerability in a co-bundled JRE + App doesn't matter, since the app has full privileges anyway and therefore opens no new holes. The security manager is only used in the applet / JNLP case, so it is in these cases where we have to get away from allowing developers to target a specific version of the JRE. These bug fixes are not all backported to all old versions of the JRE, there is instead a "security baseline", or version of the JRE that forms the baseline -- you can't target versions of Java older than the baseline. Except in some number of edge cases. The whole thing is problematic and I'm afraid that the only real straightforward answer that I can see is to co-bundle. The bottom line is that in the applet case, we *have* to push people to the latest and greatest or we're going to be a constant security hole.

Now, that of course makes compatibility even that much more problematic. For CSS our plan is to introduce new stylesheets in the future when the visuals need to be updated (ie: the successor to caspian) so that the old apps don't just look completely different overnight. But bug fixes will do this sort of thing to you from time to time.

Really I don't see how this can work if you don't co-bundle with your applications. Any other option will lead to incompatibilities of one form or another.

> Isn't webstart kind of most of the way there in terms of a 'sparkle framework', at least as far as post install updates are concerned? Run your app and you get the latest changes (as published by the app developer). Jnlp allows me to define which versions of which jars to use, it's just that jfx is not 'normal' - and really the only reason for its special treatment is it just happened to be developed by the same house as java, otherwise (if it were an Apache or Google initiative, say) it would have to follow all the normal rules and have to play nice.
> 
> Just as a side note, slightly related to all this deployment stuff is this issue too:
> http://javafx-jira.kenai.com/browse/RT-18847
> 
> Deployment is the #1 hurdle I am facing in convincing people to move to jfx. The common response is "a webapp or a flash app just works, we don't want our users to have to install anything". I have no comeback - I'm currently writing a SpringMVC app (sigh) that should definitely be a jfx app but the client won't let me for the sole reason of deployment hassles. 

I completely understand.

Richard