Backwards compatibility and auto updates

[Richard Bair]

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
>>