Backwards compatibility and auto updates
zonski at googlemail.com
Fri Jan 20 14:13:56 PST 2012
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:
>> 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?
More information about the openjfx-dev