Live data from Hacker News

Oracle’s Java 11 trap

blog.joda.org

221–230 of 244 posts

Re: Oracle’s Java 11 trap

#221

Earlier quoted context omitted.

The USA and I've been doing it for two decades, honestly copyrights and licenses are not important to me. I have taken a fuck all attitude without consequence and will continue to do so forever.

Though it "sounds bad", this is a wonderfully practical approach. Why waste a lot of time with this BS?

Because it’s a good way to get yourself sued

Re: Oracle’s Java 11 trap

#224

Java 11? At work we haven't even started to look at the migration from Java 8...

The hell? You should just be able to take your code and compile and run it on Java 8. There aren't any major comparability breaks. Just try switching JVMs and run all your unit/integration tests (you do have tests right?) Java 9 is the one that breaks nearly everything. We attempted Java 9 at our last shop and almost every dependency we used had some exception from a removed deprecated function down there in the stac…

Java8 changes the order hash maps return keys in. Those were never supposed to be stable, but because they were in practice, you're app may think they are.

Re: Oracle’s Java 11 trap

#225

Earlier quoted context omitted.

OpenJDK is the reference implementation now so if you did find a functional difference, Oracle is in error.

I honestly don't know why anyone would keep using Oracle's version of the JDK over the OpenJDK, other than them just being used to it.

Because you are stuck to use Oracle Java 8?

Re: Oracle’s Java 11 trap

#226
post #196

Earlier quoted context omitted.

The situation is confusing but not that confusing. Java 8 has commercial features that are locked by default. You can unlock them by passing a command line flag that looks like -XX:+UnlockCommercialFeatures, so pretty hard to miss. If you use those in production, you're meant to pay. But virtually nobody does use them. In fact Oracle open sourced them all for Java 11, perhaps because of that fact. Now in Java 11 ther…

The difference is that OpenJDK N will stop receiving security fixes the moment OpenJDK (N+1) is released. LTS releases are only LTS for Oracle JDK. So no, OpenJDK by itself is not suitable for production use. To put a Java app in production securely you now need to either pay Oracle or find someone to provide security fixes to OpenJDK beyond what Oracle provides for free.

Pardon me but AFAIK all JDKs are backwards-compatible. Unless you're doing some weird sh*t which exploits JRE bugs (oh, sorry.. features). But that just makes you a bad dev as you tie yourself to the implementation rather than specification. The _unsafe_ part being removed is not bckw_compat, I give you that. But if you're tied to this hole you're doomed to become legacy code maintainer as it's not coming back.

Just upgrade to OpenJDK_v(N+1) whenever it's out. Get rid of Karaf, Liferay or whatever is holding you back. Don't become a legacy app developer.

Re: Oracle’s Java 11 trap

#227
post #10

Earlier quoted context omitted.

We just made it TO Java 8.

Java 8 is EOL in January for public support/security patches. Java 7 was EOL in 2015. What have you been doing for 3 years? I could guess, because I've been at companies doing the same. Active development and support on the product, but no time for tech debt. Java 9 and up I understand people getting frustrated with a more frequent LTS release and these weird microreleases every year.

Sometimes it's your clients that are painfully slow to update. I know a client that (a few years ago), after a lot of issues and wasted time, we discovered that they had a Sun JVM 1.5 with some bug on String.length ! And the worse thing is that they not like the idea of update to Java 1.7

Re: Oracle’s Java 11 trap

#229
post #215

Earlier quoted context omitted.

'Zulu', right? What's their angle?

They originally built it for Microsoft to run Java apps on Azure: https://www.azul.com/successstories/microsoft/ I guess they later figured it could be more generally useful and they could sell support for it.

I had no idea Azure used it.

From the article: They wanted to offer Java on the Microsoft Azure Cloud, unencumbered by complex licensing or end-user restrictions.

What are Oracle doing that their shiny enterprise offerings just have too much baggage attached even for Microsoft?

Re: Oracle’s Java 11 trap

#230
post #123

This is not new, and as per: https://www.oracle.com/technetwork/java/javase/terms/license... it was put in place in 2017 already. Seeing that the "LICENSE" of Java 8 simply points to their website, it means that they effectively changed it for Java 8 as well. So that means that even if you're running Java, you have three options: (1) Continue using it illegally, it will probably be a low risk. This is not advisable e…

The situation is confusing but not that confusing. Java 8 has commercial features that are locked by default. You can unlock them by passing a command line flag that looks like -XX:+UnlockCommercialFeatures, so pretty hard to miss. If you use those in production, you're meant to pay. But virtually nobody does use them. In fact Oracle open sourced them all for Java 11, perhaps because of that fact. Now in Java 11 ther…

Thanks for clarifying. I went back to the BCL and it is indeed correct that the commercial features are listed under the supplemental license terms. Excerpt:

THE LICENSE SET FORTH IN THIS SECTION 2 DOES NOT EXTEND TO THE COMMERCIAL FEATURES. YOUR RIGHTS AND OBLIGATIONS RELATED TO THE COMMERCIAL FEATURES ARE AS SET FORTH IN THE SUPPLEMENTAL TERMS ALONG WITH ADDITIONAL LICENSES FOR DEVELOPERS AND PUBLISHERS.

Post reply on HN