Backwards compatibility and auto updates

[Daniel Zwolenski]

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

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. 

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. 



On 21/01/2012, at 8:16 AM, Richard Bair <richard.bair at oracle.com> wrote:

> My assumption was that if you cobundle FX with your app, then you have control. True, that may also require cobundling the JRE so as not to use the system JRE. But to be honest, I'd do it that way anyhow because the JRE isn't 100% backwards compatible from release to release either.
> 
> What I think would be ideal is for there to be a Sparkle like framework for Java, such that you can get the patch-in place auto-upgrade and so forth for an app written in Java, cobundled with the JRE + FX.
> 
> Richard
> 
> On Jan 20, 2012, at 2:13 PM, Daniel Zwolenski wrote:
> 
>> I keep oscillating between every which way possible but not yet settled on a solution I'm happy with. My ideal would be jnlp+webstart (problems with multi-step installs, too many dialogs, which-jre-am-I-using, and some odd caching issues keep making me back out of this one). 
>> 
>> Is there any option that will let me control versions though?
>> 
>> I could bundle jfx in my jar and do a manual install (sadly losing webstart's nice version updates, OS detection, and other nice stuff) but this will only work up until co-bundling kicks in, since afaik, once it's part of the jre we won't be able to exclude the 'system' version of jfx from the classpath?
>> 
>> 
>> On 21/01/2012, at 7:14 AM, Richard Bair <richard.bair at oracle.com> wrote:
>> 
>>> How are you deploying your apps?
>>> 
>>> On Jan 20, 2012, at 12:57 PM, Daniel Zwolenski wrote:
>>> 
>>>> Hey guys,
>>>> 
>>>> I've touched on this before but I am a bit (ok, very) worried about
>>>> backwards compatibility and auto-updates, particularly in the area of
>>>> visual appearance, and most obviously with CSS.
>>>> 
>>>> Let's take a seemingly innocent fix like this one:
>>>> http://javafx-jira.kenai.com/browse/RT-16589
>>>> 
>>>> So now suddenly when JavaFX auto-updates itself (which I have very little
>>>> control over), some of my font sizes may suddenly halve if they were
>>>> impacted by this fix?
>>>> 
>>>> What if the fix was to do with visibility and suddenly an all important
>>>> button is no longer visible, or to do with colours and now my white text is
>>>> suddenly on a white background and can't be read. Aside from CSS, what if
>>>> the fix was to an animation class, and suddenly my animation is 'fixed' so
>>>> maybe a bug in the fade was making my node invisible, but now the fix makes
>>>> it visible when I'm not expecting it to be, etc. This has the potential to
>>>> completely break my GUI.
>>>> 
>>>> All of these *visual* aspects can't be tested with regression testing and
>>>> API compatibility tests. A UI toolkit is not like a normal Java API where
>>>> we can just say, yep it compiles and the unit tests all still work, so it
>>>> will be fine. Even if we could do this, would we want to? We need to be
>>>> able to fix visual things, and given the incredibly loose, highly-coupled
>>>> way CSS does it's selectors (one tiny change to your CSS file can change
>>>> everything) it will be pretty much impossible to do this without 'breaking'
>>>> existing GUIs.
>>>> 
>>>> The problem in my mind is that we cannot 'fix' our apps to a particular
>>>> version of JFX. This auto-update (and co-bundling) stuff is going to make
>>>> life very hard in this field.
>>>> 
>>>> What are your thoughts? Does anyone else share these concerns?
>>>> 
>>>> Cheers,
>>>> Dan
>>> 
>