I'm confused. Is this a cost-cutting move intended to push the industry towards Java 9? If a business is able to switch to Java SE 9, will they still be eligible to receive free upgrades?
The situation is quite complex. A big part of the industry seems to be stuck at Java 8 right now due to several reasons. One of them is the momentum Java 8 gained when it was released in 2017, 8 years after Java 7. It was a strong release, bringing much-awaited features to the aging Java ecosystem. Subsequent released didn't come anywhere close to that.
Another big reason is the uncertainty of the upgrade path. Java 9 was released comparatively short time afterwards, and it is set to expire... last month. [1] Unsurprisingly, many customers chose to stay with a stabilized, thoroughly tested version of Java 8, rather than switch to a bleeding edge (in Java terms, at least), untested Java 9 with a very short time fuse on it. Finally, Java 10, which has been released recently, is also due to expire very shortly - in fall 2018.
So overall this looks like a very aggressive monetization move on Oracle's part, intended to extract $$ from customers who value stability of their platform. It goes completely against the long-established tradition of stability in the Java ecosystem, which is one of the reasons many of the customers chose it, in the first place. I expect a massive migration towards OpenJDK and a backlash in the community, which will ultimately push Oracle aside.
The roadmap is quite clear, Java 11 planned to be released in September, will be the next LTS release.
Business will have one year to migrate to 10, used the 11 preview on their test systems, and eventually migrate to the next LTS release.
I applaud Oracle here, business don't do anything unless pushed to do so.
I still have to occasionally program against Java 1.4, just because there is this forgotten server no one wants to touch.
A new JDK may have breaking changes, which may require code changes, acceptance testing, deployment to many customer sites. It is not unusual for that process to take 6 to 12 months, and you certainly do not want to repeat that process every 6 months.
It doesn't need to be deployed straight into production.
Surely there will be very few things to fix by the time 11 is ready.
Preview releases exist exactly for that.
We don't need Python 2/3 dichotomy on Java.
One sets up a test machine as part of the continuous integration worflow.
The answer was to:
"So better start today making sure it runs on Java 10. It doesn't need to be deployed straight into production."
Making sure it runs on Java 10 is not the problem, I expressed myself too fuzzy.
Azul is trying to diversify their business as not everyone is willing to pay for their GC implementation. Not sure how well they would do as Java stewards.
And since when is charging money for work done 'greedy'?
Those that kind of do, are sponsored by corporations not much different from Oracle, other than some geek love.
Finally, Oracle was the company that rescued Java, so blame the others for not caring enough.
Aren't you forgetting about Linux, Firefox and Mesa graphics library to name a few? You seem to imply that all open source is amateur's work by definition, which is obviously wrong, as many large-profile, complex open-source projects are maintained by professional developers, employed by powerful companies to work for the benefit of the whole industry. Besides, it's one thing to develop GC from scratch and another to maintain an existing one and backport fixes.
> Those that kind of do, are sponsored by corporations not much different from Oracle, other than some geek love.
There is nothing wrong in being sponsored by corporations, especially if it's a collaboration between several players, as opposed to a single one. The problems only start when these corporations overtake the maintenance completely and then start leveraging it against the users.
> Oracle was the company that rescued Java
Pah'lease! Rescued... Oracle just bought Sun's intellectual property and trademarks in hopes of monetizing them later. Guess what, later is now! The only reason Java was in trouble during Sun's time in the first place is because of Sun's proprietary attitude under the pretense of safeguarding the Java standard and preventing fragmentation. It's that attitude that first caused the Java development to stall when Sun ran out of steam and now it has brought us to the spot where the project maintainer is denying us security patches.
If it would be only about donations and community, I would still be using Solaris, HP-UX, Aix, or any other commercial UNIX platform.
It doesn't matter what were their ultimate reasons, no other company besides IBM bothered to make an offer, and even IBM did not care enough to cover Oracle's offer.
Google was specially bad in this, after having torpedoed Sun with Android and not caring one second to rescue it. Why bother they already had gotten what they wanted and with luck they might just managed to get off with it.
So yes, Oracle did rescue Java, if it was up the community, maybe we would have an open source version stuck with Java 6 features and that was all about it.
GCJ has proven how much the community is able to achieve regarding Java high quality implementations.
And no, "community" doesn't necessarily mean unaffiliated developers, they can be affiliated, like I have already stated many times, and still collectively considered a community. Open source can be a collaborative effort by major players or it can be a hopeless attempt to catch up with such. For the last 15 years or even more, it has been a common practice to commoditize technologies that are widely used across the industry. Java fully fits the above description, so maintaining it by a strong community effort would be a natural fit. Actually, from what I know, it almost works like that right now, we just need to take the licensing power from Oracle's greedy hands and keep the process the same as it is.
Java 8 was released in 2014, a little less than 3 years after Java 7:
Java SE 6: December 11, 2006
Java SE 7: July 28, 2011
Java SE 8: March 18, 2014
Java SE 9: September 21, 2017
Java SE 10: March 20, 2018