What it is really happening is really simple. And I think acceptable approach. Think about how redhat company controls Redhat (distribution) and Fedora.
Fedora is free. It will get updated. Redhat (company) is the real power behind Fedora. But it does not have any enterprise support. You want enterprise support, buy Redhat subscription. And it is not like Fedora does not get security update. It gets and it is very effective.
The same relation is going to happen with Oracle Java SE and OpenJDK.
Openjdk is free. It will get updated. Oracle is the real power behind Openjdk. But it does not have any enterprise support. You want enterprise support, buy OracleJdk subscription. And it is not like Openjdk does not get security update. It gets and it is very effective.
As far as I can tell, the reason Oracle is the sole maintainer of Java is mainly historical (Sun legacy) and because no one felt an urge to do anything about it before. I'm sure it's going to change now.
Why? Neither Google nor IBM particularly require Java bug fixes from Oracle. Google maintains an in-house OpenJDK already and IBM actually maintains an entirely separate JVM. Also Google is hardly famous for its long term commitment to stable APIs and old versions of software, quite the opposite.
It doesn't make much sense for a company to pay for the expensive work of finding, fixing and backporting bug fixes to years old software .... all for free.
Or use CentOS. Oh wait, that's exactly what tens or hundreds of thousands of small businesses did and keep doing even today. Besides, that's not even a good comparison - Red Hat Linux was and is mainly about packaging other vendors' software, as opposed to Java, which is a monolithic piece of software developed as a single project.
> Google maintains an in-house OpenJDK
Didn't know that. How can they do that while keeping compatibility with Oracle's OpenJDK? Well, this information just reinforces my point, actually. Google is already in position to ditch Oracle as an upstream and unite with other parties to build a new foundation for open-source Java.
> Google is hardly famous for its long term commitment to stable APIs and old versions of software
Nobody likes to use other people's buggy code. I think you are mixing up two different things. Google does iterate their own software at a fast pace, but that doesn't mean it doesn't want the underlying infrastructure to be as stable as possible.
Or you can use Openjdk.
This isn't the slimy Oracle play. That will be when they stop releasing bug fixes in advance into OpenJDK, and do so without any back ports, backing information or tests (see: MySQL)
There used to be a lot of compatibility issues between the 'official' Sun/Oracle JDK and OpenJDK, but those seem to have been ironed out as of JDK8.
But this is great, giving a boost to openJDK (and maybe even Google's Android Java), as Oracle did for Hudson->Jenkins. By the time they try to claw it back, it will be too late.
You never know with these people..
In fact, Java 9 is already out of support (since last month). The next viable Java version after Java 8 is Java 11, which is an LTS version. Java 11 will come out around September this year. So in reality, this means organizations have a couple months to migrate everything from Java 8 to Java 11. Laughable.
Java shops are used to being able to stay on old releases for near-forever, but they need to adapt to Oracle's business model being to charge for Java support. It was Sun's monetization model for Java too; they just sucked at it.
Each Python version is supported for 5 years. So if you start building on Python 3.6 you are guaranteed to have a supported version till 2021. Upgrade to 3.7 (due out in June) when released and you'll be set till 2023.
So yes, Python does offer free LTS.
This is just Oracle being Oracle and finding another way to fleece their Customers, many of which were Customers of Sun who would never pull a move with such contempt like this.
Definitely Oracle being Oracle.
Now, there could be a vulnerability in one of the packages you built against, but exploitation of that is going to also depend on whether that specific program uses the vulnerable bits of code, using inputs controllable by an attacker.
It's mostly moot compared to the story here anyway, as none of the others are beholden to any entity resembling Oracle.
It just sounds strange that I must restrict myself from upgrading. If someone wants to protect its software from unauthorized use, they use electronic licenses, expiration, etc.
What this means is that there is nothing to stop you from using the software for commercial purposes, but you need to be prepared for a visit from Oracle's lawyers.
Let's just leave all this for Oracle's lawyers to decide. I'm sure it will turn out just fine :)
Does this foreshadow that Oracle Java SE 11 will be licensed or is this just a fee to force users to move on to the latest version?
* The latest version of Java will always be free to download.
* There will be new versions every 6 months with zero overlap.
* LTS versions are available every 3 years, but only for paying customers
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.  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.
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.
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.
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
It it just the case of change the runtime binary and continue using the version the code was developed for? Probably as a matter of regression tests, it is somewhat more risky than just using a security fix, but it would still be very rare.
"These applications may run on the Java platform and be dependent on Oracle Java SE 8 updates beyond 2020. Accordingly, Oracle recommends you contact your application provider for details on how they plan to continue to provide application support to you."
To me this reads like they will intentionally "update" the user's Oracle JRE such that it will fail to run applications by non-paying "business developers".
If true I suspect the end-user runtimes will check jar's to see if it is signed by the "business developer", and if there is a certificate signed by Oracle confirming the "business developer".
The developer can not prevent the user from upgrading their Oracle JRE's.
This should have no bearing on users using OpenJDK's JRE, but it may have bearing on FOSS developers if a substantial fragment of their users are running Oracle's JRE, depending on the interpretation of "business developer".
I imagine the Oracle JRE will show an error message dialog to the player, containing a URL to this or similar page.
How is that even remotely unreasonable though?
The game example is poor for a different reason; Oracle don't seem to care about desktop apps anymore and they want you to bundle the JVM with your app anyway. Hence new tools like jlink and javapackager.
I suspect you aren't quite sure about what "support" means here. It doesn't mean your app suddenly stops working one day. For most apps it'll make no difference in fact.
I have a slightly biased perspective because I do pen testing, reverse-engineering, and other "hacking" work, but this is going to cause me a lot of grief because Java 9 and 10 started making it clear that Oracle wants to restrict use of reflection significantly - maybe remove it altogether. Clearly there are ways for me to get around it, but a LOT of the tools I use are going to be broken by default.
Googling "All illegal access operations will be denied in a future release" indicates it's not just my kind of software, either.
The point of the new warnings is to try and start slowly weaning the Java ecosystem off the use of internal APIs, something to which it has become quite accustomed.
Anyone got a ballpark figure?
OpenJDK is Oracle. They're the same people. If Oracle stop releasing bug fixes to the open source project OpenBSD isn't going to step up and suddenly start doing backports all themselves.
Want updates for legacy? Pay up.
Sorry, I might be a bit wrong. I thought non-business users wouldn't get free updates too.
>Or they'll no longer be entitled to updates and bug patches
They aren't converting a free product into a paid one. As I understand you can use whatever you're using right now, it's just that you won't get free updates.
IIRC Microsoft does this with old versions of Windows. Want updates for XP? Pay us and we'll support it with bugfixes.
Or don't pay us and get your support on 3rd party forums.
Sorry, I might be a bit wrong. I thought non-business users wouldn't get free updates too.
Because the implication is that this is a surprise, a novelty -- that it's "new" and hence News -- meaning that something changed and that it was a motivated change.
Which isn't true. Every enterprise software company publishes policies about how much support it will give its products well into the future. I work for Pivotal, we have a general support/lifetime policy and aim to give explicit guidance for every single release we publish of everything we produce.
That folks outside the enterprise universe are learning now what Oracle outlined years ago doesn't make it an evil scheme on Oracle's part. It just means we move in different circles from enterprise buyers, who have different problems and motivations.
I honestly can't believe I'm defending Oracle. Seriously, I never thought I'd see the day.
Java SE 8 business users do not need to buy a licence to keep using Java from January next year. That's not true. It's false. They can keep using the current versions of Java 8 as long as they like, for free.
What won't be free is for Oracle to give them new updated versions of Java 8.
This has _always_ been the case. Oracle always stops supporting old Java releases at some point. Do you think they should maintain them forever for free?
An alternative is use the AdoptOpenJDK  that aims to provide unofficial LTS support.
Well, that's a NEW development. And a major one at that.
Companies used to be able to rely on the same version of Java for years AND get security etc updates, without paying Oracle (and before that, SUN).
They might still do that, with OpenJDK, but not with Oracle releases anymore.
What they are doing is stepping up the challenge of insisting in e.g. using Java 1.4 in 2018 (Yes I do know a few such cases).
Companies who won't shift of a JDK know this, that's why they pay for the privilege. They pay Oracle, or they pay someone to support an OpenJDK like Red Hat.
It's new for Java.
We don't care, for the purposes of the discussion, if it has been how things are since forever at SomeOtherProductOrLanguage.
We're not taking about the relative novelty of this release model (or its merits), but about how things are different now for Java releases.
Previously that was years on end.
People have already had years of support for Java 8 including support updates. By 2019 they will have had five years of it. Nothing's changed.
What's changed is that this wont be the case anymore for 9, 10, 11, and so on.
Plus, after 9, each new release will be out in 3-6 months (can't remember which) instead of years. And support for the previous n-1 release will end in the same day.
Plus, despite their frequency they'll have major language changes (whereas usually Java did much smaller scale changes + full backwards compatibility).
It is a pain to update huge systems to the latest Java, latest version of Haskell’s compiler and libraries, move to Python 3, etc., etc. but there is also a real cost to long term support for old software, I am especially thinking of important security updates.
However, apps written specifically for Java 9 (e.g. using the new modules system) wouldn't work on older versions of Java.
I had to double-check how old Java 8 was, and in the process I've learned that it was initially released way back in 2014 and currently Oracle is already working on releasing Java 11.
What matters is when Java 9 became available. I.e. how much have they had to migrate from Java 8 to its first successor: Java 9.
Java 9 is available since summer 2017. So that means companies will get only 1.5 years to migrate all of their Java 8 apps to the next available version. Which is very, very little for large organizations who may have many hundreds of apps running on Java 8.
For 8->9, this announcement means it'll be 17 months of support after Java 8 is no longer current, which is in perfectly line with what they've been doing.
So in reality, this means organizations have a couple months to migrate everything from Java 8 to Java 11. Laughable.
Because of the increased release cadence, there is also no guarantee that there won't be breaking changes between LTS versions. (Java 9 already became the first Java release ever to actually remove deprecated classes, although in a very minor way).
Unfortunately, many widely used libraries depended on said exposed internals and now stopped working.
Many libraries have since been updated, but often in form of new major releases and not all libraries give the same backwards compatibility guarantees as Java itself does.
So even if you yourself were a good citizen, relied only on public interfaces and got rid of uses of deprecated API in a timely fashion, then some libraries you depend on might not have done so or might have changed a lot since you last updated them.
^ There, that could be a problem. I have a couple of anfient Java apps that I have no source code for. Some of them were written for Java 7 and no longer work with Java 9. (Fixable with a tweaked OpenJDK JRE, yes, somewhat)
That's 4 years. In the Java world releases could take way more than that for a SINGLE release.
So, this "8 is 4 years old, we're at 11 now (and n+1 every few months)" is a totally new model for Java.