Why is almost everything in the API final

Richard Bair richard.bair at oracle.com
Tue Sep 3 16:31:24 PDT 2013

>> None of these points are suggesting the problem is with WebStart's implementation, they all hold even if WebStart were completely bug free. They're just the natural side-effect of a shared install system.
> Actually, one of the best things of Java is that in like 99.9% of the cases, my app will run flawlessly on whatever version of the JDK or JRE is installed... on multiple platforms.  If Java goes down the road of requiring testing against a specific JRE (and thus specific platform by extension) then that is its biggest advantage lost.
> In fact, any framework that does not aspire to do the same (being backwards compatible to a flaw) is not a framework I'll consider for production use.  I want to be able to upgrade, and at most run my unit tests to have the confidence that it will perform as expected.  There can always be mistakes, both in the frameworks or in my code doing something that was undocumented or incorrectly interpreted, but in the end backwards compatibility is what makes or breaks a framework -- a big reason for that is that such frameworks are actually designed with some care, exactly because they aspire to be backward compatible... and a good API is everything.

When you have 9 million developers and hundreds of millions of apps, any change we make breaks somebody. Every bug fix. Everything. For any one developer the chance of breakage may be less or greater (we get reports from some customers who spend 6 months fixing breaks between major releases and others from developers who've never experienced a break). Having seen the carnage, I myself would avoid using a shared install if possible.

That is a separate issue from trying to maintain backwards compatibility. Having to rewrite a large chunk of your app to move from version N to N+1 is obviously not desirable, but having sat in this seat for a while now, I wouldn't personally risk running my app against any random release of *anybodies library*, if I could help it.


More information about the openjfx-dev mailing list