Backwards compatability (forked from Re: Tooltip for disabled controls)

Daniel Zwolenski zonski at
Sat Apr 6 06:31:34 PDT 2013

Agree, we need the alternative in place so that we can all happily let go
of applets and webstart.

It's easily done and in the pipeline but moving slowly. One of the big
reasons it hasn't happened is because the delpoyment guys are often dragged
off to fix urgent security problems around web based deployments. When they
do get time to look at future features they are instantly handicapped by a
large blob of legacy applet and jnlp code that the newer stuff is
intertwined with.

As far as I know, there's also only two of them working on it, which is not
much when you consider what cross-platform deployment invovles and how
important it is. Also these two guys have inherited this code base so they
also have to pick it up from scratch and there are a lot of strange things
in it. So it's sloooooooow.

My old song though: nobody loves deployment enough. For me it is still bug
#1 and should have a team of 10 people working on it with priority

On Fri, Apr 5, 2013 at 6:03 PM, Tom Schindl <tom.schindl at>wrote:

> Self updating applications is a very good explored area for native
> applications and even for Java it can be done - Look at your IDE it has
> such a feature.
> We are deploying RCP-Apps this way which are in our case based upon
> Eclipse so we can make use of the so called p2-framework which does all the
> magic for us, all we push to our servers is the latest versions of our
> bundles. I guess the same is true for Netbeans-Platform apps.
> Tom
> On 05.04.13 23:48, Mark Fortner wrote:
>> The problem with dropping Webstart support is there isn't a real
>> alternative yet.  The very real problem that webstart fixes, is that it
>> puts distribution control in the hands of the developer.  If something is
>> broken, I can get a fix out in a few minutes.  If I have to go through a
>> separate department to deploy it, then it's going to take longer.
>> Creating OS-specific distributions also creates additional headaches.  In
>> the latter case, I'd really like to just deploy the app with some metadata
>> in a JAR and let the JRE figure out how to display it in the OS, how to
>> interpret the dock icon attribute, and the application name, the
>> preferences menu, etc.
>> Cheers,
>> Mark
>> On Thu, Apr 4, 2013 at 5:37 PM, Daniel Zwolenski <zonski at>
>> wrote:
>>  On Thu, Apr 4, 2013 at 7:57 PM, Richard Bair <richard.bair at
>>>> wrote:
>>>   From the front line, I'd like to just highlight the fact that
>>>>> backwards
>>>> compatibility has so far been largely lip service rather than reality.
>>>> All software is going to have breaks in new versions (if you're fixing
>>>> bugs, you're changing behavior, and that's going to break somebody). But
>>>> there is a LOT of stuff we have wanted to do but haven't done for the
>>> sake
>>>> of compatibility. And note that there are different levels of
>>> compatibility
>>>> and neither Java nor JavaFX is committed to 100% perfect compatibility
>>>> between any release (major, minor, or security). We just try to manage
>>> the
>>>> type of incompatibility.
>>>> For example breaking binary compatibility is a huge issue. Breaking
>>> source
>>>> compatibility is still a major issue, but not quite as bad. Breaking
>>>> behavioral compatibility is less bad -- might be major, might be minor
>>>> --
>>>> and within scope for consideration. We use the same rules here as the
>>> JDK,
>>>> which has never been 100% compatible.
>>>> I would disagree we have only paid lip service to compatibility. There
>>> are
>>>> a number of issues in JIRA that have been closed as won't fix because of
>>>> compatibility. We're not just talking about it.
>>> Controlled change is happening at the moment, but regardless of the
>>> extreme
>>> effort put in by you guys (and I agree, there has been strong, careful
>>> and
>>> committed effort to being 'as backwards compatible as possible'), the
>>> reality is that 100% backwards compatability cannot realisticly be
>>> achieved
>>> and 99.9% backwards compatibility is enough to cause problems. Each
>>> release
>>> of JFX definitely has the potential to break running apps (and already
>>> has
>>> for me twice).
>>> The difference between binary, source and behavourioul compatability
>>> might
>>> affect how much time I have to spend fixing the problems, but a break at
>>> any level (and indeed even just the potential of a break) means I have to
>>> constantly retest and tweak my apps with every release. With auto
>>> updating
>>> JREs and web deployment models (which I stupidly used at first thinking
>>> they'd be a good option) apps that are out in the wild are breaking. ´
>>> Behavioural changes are actually much harder to find than code ones and
>>> more often than not it is the user that finds them so I don't really
>>> agree
>>> that these are 'less bad' for me on the front line. Nothing is worse than
>>> the user finding problems before the developer does.
>>>>  builders will break soon,
>>>> Actually according to my plan, builders won't break for several more
>>> years
>>>> -- just get removed from the javadoc & marked deprecated.
>>> Pretty sure that's 'soon' on the JFX timeline as far as changes go ;)
>>> Also, what you've just said to me is that in several years time I am
>>> going
>>> to get a call from a vendor who I built a product for saying that their
>>> app
>>> just stopped working with some strange exception about ClassNotFound.
>>> i.e.
>>> I will have to upgrade some code that is 4 years old that I haven't
>>> touched
>>> in that time and I will have to check it all out, get setup again,
>>> rebuild
>>> a test database, build, test, redeploy, etc, etc. Just so I can then add
>>> the fxbuilders.jar to the path. All the time it takes me to do this, the
>>> client will not be able to do their job and will be losing money, etc.
>>> For me as a developer that is about as non-backwards compatible as it
>>> gets.
>>> Also, note that I voted yes to making this change and I was aware of the
>>> consequence. My points here are:
>>> 1. Let's try to move away from the web based options as soon as possible
>>> since they have so many problems including this issue, and instead give
>>> people better options so they don't miss the web based ones (currently
>>> telling people they will lose web based will cause anger because the
>>> alternatives are not fully implemented or understood).
>>> 2. When weighing up the choice between backwards compatibility and
>>> optimal
>>> platform, give both a high ranking, but optimal platform slightly higher
>>> (as you're planning to do with builders). i.e. if the break to old apps
>>> is
>>> small or easy to fix and the win to the platform high, then I'd say be
>>> open
>>> to doing it.
>>>>  Also worth noting is that cobundled JREs (and eventual app store
>>>> deploys)
>>>> don't suffer from backwards compatability issues since the jre is tied
>>>> to
>>>> the version of the app code. Only web based deploys (applets and jnlp)
>>>>> suffer here.
>>>> Sort of. There are two main issues that come up with respect to
>>>> compatibility. The first is "does my running app break". With Applets &
>>>> WebStart we face that problem, but as you correctly note, you don't with
>>>> app co-bundles. However the other end of it is what happens when you own
>>> a
>>>> large application and you need to ship it over several (perhaps 10 years
>>>> worth) of updates. You adopt JavaFX at 2.2, but 2.2 doesn't have all the
>>>> features you need. But behold! the features are coming in 8. So you
>>> upgrade
>>>> to 8 and spend 5 months converting your app over. And the world has
>>>> moved
>>>> on and you need some more features, or bug fixes, and lo! they are
>>>> coming
>>>> in 8 update or 9. But son of a gun, you have to spend another 5 months
>>>> overhauling your app.
>>>> So even though you are using an app cobundle, you are still suffering
>>> from
>>>> backwards compatibility issues. There just isn't getting away from that.
>>>> The people who aren't affected are the ones that write "fire and forget"
>>>> applications. That'd be, consultants :-)
>>> The main difference is who controls when the upgrade happens. In web
>>> deployed options, Oracle decides when a new release goes out and gets
>>> installed on client machines. The break happens in front of the clients
>>> eyes and the developer has to play catch up. This is bad customer
>>> relations.
>>> In the co-bundled model the developer controls when their app is ready to
>>> move up to the newer JRE. The break happens in the development lab and is
>>> fixed before it goes to the client. This is good customer relations.
>>> Yes, backwards compatibility should be a concern (much as it is for
>>> Spring,
>>>   Hibernate, etc) so that if/when I choose to upgrade the fixes are as
>>> simple as possible (i.e. a week instead of 5 months), but my vote is for
>>> a
>>> better platform to take higher ranking over backwards compatibility (i.e
>>> don't change for fun, but do change when it makes things significantly
>>> better).
>>> Obviously just one voice among many and I'm sure others will have
>>> completely different opinions. Just giving my feedback on what would work
>>> best for this one developer.
>>> p.s. 'Fire and forget' is the customers choice not the consultants. i.e.
>>> they have budget X for an app and it does the job for the next 5-10
>>> years.
>>> Then they get a new budget and decide they want to upgrade (or if I get
>>> my
>>> way rebuild). I'd guess that's a very large percentage of apps out there.
>>> Pretty sure Oracle is one of those style of consultants too (pretty sure
>>> because I have worked for one of the largest Oracle resellers in Sydney
>>> doing exactly those style of projects) :)

More information about the openjfx-dev mailing list