Hacker News Reader

Comment by LudoA | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com