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

[Tom Schindl]

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