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

[Mark Fortner]

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 gmail.com> wrote:

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