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

[Daniel Zwolenski]

On Thu, Apr 4, 2013 at 7:57 PM, Richard Bair <richard.bair at oracle.com>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) :)