Hacker News new | past | comments | ask | show | jobs | submit login
Java SE 8 business users must buy a licence from Jan 2019 to receive updates (v3.co.uk)
148 points by stedaniels on April 25, 2018 | hide | past | favorite | 121 comments



I don’t understand the backlash for this. It seems people do react without investigating the issue when they hear Oracle name.

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.


This is not about enterprise support. It's about security fixes and bugfixes. If you're a business, you will have to pay for these fixes or roll with their 6-months release cycle. Selling security fixes is quite unprecedented for a project of this scale. Furthermore, it emphasizes Oracle's power over its users, and let's not forget that these users are sometimes as big or bigger as Oracle itself (IBM and Google to name a couple). So they could potentially organize and take over stewardship of the project to ensure that no drastic changes of this sort will ever happen again. I don't see any reason not to. 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.


How is selling security fixes unprecedented? That's basically the entire Red Hat business model in the early years - yes the fixes are "free" if you want to spend all your time downloading and recompiling software, or you can buy RHEL and get a steady stream of backported fixes to your server for years. But it'll cost you.

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 you can buy RHEL

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.


>If you're a business, you will have to pay for these fixes or roll with their 6-months release cycle.

Or you can use Openjdk.


If you are willing to support yourself, you can use OpenJDK. If you want to rely on a third party vendor (paid or free like a linux/BSD distribution) to stay on top of bugs and release patched versions, they'll likely 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)


I hope you're right, that the current situation for OpenJDK users remains basically unchanged. I pretty much stick to OpenJDK these days, anyway.

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.


I wonder if this means a boost of marketshare for Zulu.

https://www.azul.com/downloads/zulu/


Yep, same for Red Hat's support for OpenJDK (which goes up to October 2020 for OpenJDK 8: https://access.redhat.com/articles/1299013).


Did you find anything on their support policy for sec updates for older versions?


Surprise!

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.


Isn't Oracle the main sponsor of OpenJDK? They sure want you to move to an up to date (ie. 9 or 10) version of it.


They are - but I don't think they can somehow unrelease OpenJDK 8.


Well, they did it with Open Solaris.

You never know with these people..


Was Open Solaris also used by close to 10 million developers?


Never underestimate Oracle's power to shoot themselves in their own feet.


The only thing that is weird here is that Oracle was able to get a release of Java out in a year. Once the second public release is made, you needed a business license in order to get security updates for older products. Businesses are the only ones slow to update. Why is it immoral for Oracle to charge a business for their maintenance services?


If you lie down with Oracle you're going to get fleeced.


This is possibly ok, actually. Java 9 and 10 have been released; Java 11, the next long-term-support release, has a release date of September. So this applies if you're on a 5-year-old version of Java and choose to run Java 8 rather than update to 11. http://openjdk.java.net/projects/jdk/11/


Java 9 was released end of September 2017... That's less than 1.5 years to migrate all your apps (possible many hundreds) from Java 8 to Java 9. Way too short.

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.


This is all accurate. However, it is not like Java 9 was being developed in private, and I doubt many shops even started to look at support once it was RTM.

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.


In addition to this, Java 9 introduces changes that make the migration non-trivial


YMMV but I would be hard pressed to name any company I produced Java-based software for which even ran Java 9.


What other runtime offers free LTS? Does Python? Does Node? Go? Erlang? Haskell? How is it getting fleeced to be able to buy (instead of get for free) something that others don't offer at all?


Python does LTS, although they don't explicitly call it LTS:

https://devguide.python.org/#status-of-python-branches

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.


And java 8 also has free support for 5 years (released Mar 18, 2014, free updates end on Jan 2019. (ok, 2 months short of 5 years.) The charging for support is for the stuff older than 5 years - that is the long-term support being charged for. This isn't anything new for Oracle or many other companies.


The problem is that you have very short window to migrate to Java 11 (next LTS) with Python there is no such problem as really each release is LTS, so you have three years to migrate from 3.6 to 3.7.


Er, hate to break it to you, but some of the ones you list actually do offer free LTS releases, e.g. Node: https://nodejs.org/en/download/


Node LTS has 30 month of support JDK 11 will have a similar one of three years. Less overlap though.


You could always use a language with a spec and multiple implementations. Common Lisp and C have both been around for a long time with specs that have seen wide open source and commercial implementation.


You're right, that's very generous. But as they don't maintain the VM and they don't have a big standard library, it's probably an order of magnitude cheaper than maintaining the JDK.


I can't think of any other popular language that requires payment for security updates. Node supports an LTS version, Python support for 2.7 extends to 2020 [1] despite Python 3 being released in 2008, Microsoft still provides support for .NET 3.5 Framework released in 2007. Java 9 was released in July, 2017 that's nowhere near sufficient time to force an upgrade.

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.

[1] https://www.python.org/dev/peps/pep-0373/


Ubuntu even provide an entire OS supported with security updates free of charge for five years. Granted, they have considerably more developers and commercial support from Canonical, but most of these languages have some kind of sponsorship deal in the background.

Definitely Oracle being Oracle.


Does the concept of LTS really make sense for languages that produce compiled executables? Taking Haskell as an example, the usual output may have dependencies on some typical system shared libraries, not so much on the ecosystem from which it was compiled. If static compilation is an option, then there is very little runtime dependency on anything besides the OS.

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.


What does it mean: "business users of Java SE 8 will no longer receive public updates for the software after January 2019", "Those using Java for individual, personal use, will continue to have the same access to Oracle Java SE 8 updates as they do today through at least the end of 2020.". What's the difference between business and personal use? I'm downloading JDK from oracle website and using it for business use. I couldn't care less what Oracle thinks about it. Will it work?


I guess what you're really asking there is "is Oracle litigious?"


I just wonder if it's about some business JDK (different from personal JDK) or I'm just forbidden to download updates from Oracle website after January 2019 for business use? Can I stay on latest available JDK 8 update then?

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.


Traditionally, Oracle make their software available to anyone with a development license, meaning you are not allowed to use it in production for commercial use. This isn't so unusual, Red Hat's JBoss can be freely downloaded, but you need to click accept on a license agreement.

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.


>couldn't care less what Oracle thinks

Let's just leave all this for Oracle's lawyers to decide. I'm sure it will turn out just fine :)


Oracle announcment link: https://java.com/en/download/release_notice.jsp

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?


In summary:

* 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


This is Oracle. I am sure they will do their best to fleece their customers. Then sue customers for skin and cartilage.


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?


Okay, replying to myself after a couple of quick Google searches.

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.

[1] http://www.oracle.com/technetwork/java/eol-135779.html


Every time people suggest OpenJDK to move away from Oracle, they should learn who actually writes OpenJDK code.

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.


There's good business opportunity is to fork OpenJDK and backport important patches. May be IBM or Zulu will do that. Might become new de facto JDK. I know that I'm stuck with Java 8 for years even if it means that I won't upgrade JDK at all.


IBM preferred to let Oracle buy Sun than invest into covering their offer.

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.


If you are willing to pay for support then why not just buy it from Oracle?


Another company might be less greedy or offer it for free (to promote their other products or just as a good will).


The only other companies that have been proposed all make money by charging for support.

And since when is charging money for work done 'greedy'?


I don't see how OpenJDK is different from other big open source community-managed projects. If Oracle is not willing to maintain an up-to-date version of the JDK, there are a lot of businesses big and small, as well as individuals, who will be interested in creating a governing body to oversee bugfixing in old releases, potentially even taking over stewardship altogether (which is probably a good idea, given Oracle's dubious reputation and this boundary hostile move).


For starters none of those projects has parity with Java's JIT and GC implementations.

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.


> For starters none of those projects has parity with Java's JIT and GC implementations.

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.


Linux, Firefox and Mesa wouldn't be where they are without the generous contributions from IBM, SGI, Google, Intel, Microsoft, Compaq, HP, Cray and many others.

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.


You are drawing conclusions based on arbitrary facts. GCJ has always been going against the grain both politically and technologically, no wonder it ended up where it did. There are strong efforts and weak efforts. The fact that many projects fail doesn't mean that it's a bad idea for this specific project to be maintained by a community.

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.


Except that your beloved "Java community" working on the OpenJDK and driving JEP's implementation are mostly the ex-Sun employees now Oracle employees, that no one else bothered to offer an job.


That can change.


Upgrading to a new JDK every 6 months is pushing a bit too hard if you ask me. In case of JDK 8 -> JDK 11 (LTS to LTS) you even have only 4 months.

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.


So better start today making sure it runs on Java 10.

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.


My main point with Java upgrades is not source code, but different behaviour in production. Or some side effects you didn't get in testing.


You don't test just for a couple of hours.

One sets up a test machine as part of the continuous integration worflow.


Yes, but with every large applications I've been bitten by non-functional problems in production with major Java migrations, as non-functional testing is usually not as extensive as user testing.

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.


> the momentum Java 8 gained when it was released in 2017, 8 years after Java 7

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


Yes, 2017 was a typo, thank you. 2014 is 8 years after 2006.


You will need to upgrade to JDK11. Or find another JDK 8 support option e.g. RedHat or Azul


Confused here. When I compile a Java program, I can specify the target platform. Even if I'm running Java 9, I can target Java 6.

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.


What does this mean for Eclipse users? We do a lot of micro controller projects and every SoC comes with an IDE which is often Eclipse with extensions. These IDEs are often free. How will this affect that situation?


Eclipse seems to be the "user" w/r/t Oracle, if I'm reading this right.


You can always use openjdk right?


In most instances, the Java-based applications you run are licensed separately by a company other than Oracle (for example, games you play on your PC are likely developed by a gaming company)," the firm announced in a statement.

"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".


Sounds more to me like if you're a business using software that only works on Java SE 8, and tomorrow Java SE 8 breaks in Windows 10.next or some huge security hole is found, your choices are "pay Oracle" or "convince the software vendor to upgrade the software to Java SE 9+". It's up in the air if Oracle prefers the former (=they make money) or the latter (=they can drop support for SE 8 and save money)


but how would that apply to their explicit example of a Java SE 8 computer game ? and the next paragraph is a thinly veiled threat to developers of such a hypothetical game: developers, pay us or we will direct your players' complaints to you (or have fun explaining to all your players on different platforms to either install openjdk or fully remove and reinstall some old copy of Java 8 SE from some mirror somewhere, and explaining them they must from now on ignore the update notifications).

I imagine the Oracle JRE will show an error message dialog to the player, containing a URL to this or similar page.


developers, pay us or we will direct your players' complaints to you

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 think it would be very unreasonable if a player's "updated" JRE would refuse to run a non-updated application that perfectly worked the day before, on the simple basis of not the developer not paying Oracle. Consider a user on windows with Oracle JRE, using some FOSS Java software. Suddenly he can't run his Java application, because the FOSS developer does not pay Oracle, and the FOSS developer gets flooded with hate mail.


Who is suggesting that will happen?

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 noticed this as well yesterday when I needed to install a JDK on my work MacBook.

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.


There is no sign reflection is going to be removed. That wouldn't be possible anyway. The "denial" of use of internal APIs can be disabled with a command line switch.

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.


At work we're migrating to openjdk obviously. But I'm curious what is the cost of a commercial Oracle JDK license? Is the price per server, per cpu/core, per users?

Anyone got a ballpark figure?


At least Azul charges $12k per year for basic package (0-25 servers). Oracle won't be any cheaper or few times more. That will be no-go for most mid-size and small projects.


well basically they force people to openjdk.


Who is fixing security bugs in old openjdk releases?


OpenBSD uses OpenJDK8 in -stable.


And OpenBSD has large numbers of skilled VM engineers sitting around doing nothing?

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.


... which they most probably will shut down next year. Remember Open Solaris? ...


OpenSolaris does still exist, it was forked and continues under the OpenIndiana name now. I think Oracle's major claim over the project was the use of the 'Solaris' name for copyright reasons. I hope that three letters would be a lot harder to assert copyright over, but I'm not holding my breath.


Trademark... trademark reasons.


You're right, I get those mixed up.


Title is baiting.

Want updates for legacy? Pay up.

--------- Edit:

Sorry, I might be a bit wrong. I thought non-business users wouldn't get free updates too.


How is it baiting when it perfectly summarizes the whole news, with no misguidance, no unbased speculations? "Java SE 8 business users must buy a license from January next year" is not a luringly reworded way that (mis)guides the reader to think that something exciting is going on which -- this part is very important for something to be a bait -- actually is just a speculation or is not happening at all. It rather exactly is what is happening.


It's doesn't summarize, because the key thing is in the second line of title.

>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.

--------- Edit: Sorry, I might be a bit wrong. I thought non-business users wouldn't get free updates too.


> How is it baiting when it perfectly summarizes the whole news, with no misguidance, no unbased speculations?

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.


Because those users can avoid paying anything if they actually bother to upgrade to a newer version.


The title _is_ inaccurate.

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?


Yes, nothing new here. Oracle will stop free updates to LTS [1], and users of Java will need to either stay on the bleeding edge releases or pay for LTS.

An alternative is use the AdoptOpenJDK [2] that aims to provide unofficial LTS support.

[1]: https://react-etc.net/entry/oracle-to-stop-providing-a-free-... [2]: https://adoptopenjdk.net


>Yes, nothing new here. Oracle will stop free updates to LTS [1], and users of Java will need to either stay on the bleeding edge releases or pay for LTS.

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.


Not really, you had to have an Oracle account to have access to legacy JDKs and sign an agreement that you were aware of the security issues of relying on outdated releases.

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


It's not new at all. It's not economical for anyone to provide general engineering support for any JDK for all time. People aren't up in arms that JDK 1.1 isn't being supported.

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 not new at all. It's not economical for anyone to provide general engineering support for any JDK for all time. People aren't up in arms that JDK 1.1 isn't being supported.

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.


Oracle did this for 7 and I believe 6 as well. Java 8's time ran out, it was as simple as that.


Nope, it's a new announcement. This is not about 8 running out either, it's about 9 (and onwards) having a few months update cycles (and Oracle updates and security patches).

Previously that was years on end.


I was confused by everyone focusing on 8.


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

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.


As you said: "People have already had years of support for Java 8 including support updates".

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


Thanks for clarifying that. So, if businesses always update in a timely way to the latest release there is no charge, right?

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.


Or get an JDK from Azul or RedHat or another JDK provider e.g. IBM. All it says if you want to get a new Oracle JDK 8 once JDK11 is out you will need to pay, if one gets it from somewhere else ask them not Oracle.


Will it be possible to download the current version of Java 8 JDK which is currently free? Or will all existing downloads also disappear behind a paywall?


A bit cheeky that they do this at a time when moving on is particularly expensive. Nobody would have had issues with this sort of behaviour between 6 and 7, or even 7 and 8, because backward compatibility was massive. From what I understand, that's not exactly the case with 9.


Pretty sure that Java 9 should still fully support apps written for older versions of Java.

However, apps written specifically for Java 9 (e.g. using the new modules system) wouldn't work on older versions of Java.


It's a little more complicated than that; for example, a good many clojure libraries were broken by Java 9. I haven't been writing clojure day to day for about six months, so I don't know how things are looking just now. But it would be a non trivial task to migrate a lot of clojure apps over.


I don’t think that many libraries were broken by Java 9. There was a bit of tooling, and ClojureScript required adding a module, but I haven’t come across any major broken libs yet. Let me know if you have examples I can add to my Clojure Java 9 upgrade guide: https://www.deps.co/blog/how-to-upgrade-clojure-projects-to-...


Nail in the head.

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.


The release date of Java 8 doesn't matter. Nor does the fact that they're working on Java 11 (which is only because Oracle just started doing fast releases).

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 the Java 5 -> Java 6 transition, Java 5 was publicly updated for 3 years after Java 6 was released. 6->7 saw 6 supported for 21 more months, 7->8 was a rather short 13 months.

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.


Except Java 9 is already no longer supported. 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.


Also, once you get to Java 11, you need to either pay for the LTS version or be prepared to update Java every 6 months with no overlap.

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


Older Eclipse based software does not work with Java 9.


Are there many breaking changes between java versions? I know Microsoft tries to avoid that with .net and upgrading to a new version is often just changing a setting and recompile, but I have no experience with java.


due to the modularization effort that went into Java 9, a lot of previously accidentally exposed internals have become inaccessible.

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.


recompile

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


It is the same with Java. The only breaking changes I have seen were when old code used things that became keywords in newer versions. That said, new version of Java means a new runtime and all the issues that can introduce. Running an application on the new version has always been pretty easy. It's recertifying it and possibly tuning things like garbage collection that make this daunting for a large organization.


>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.

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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: