Hacker News Reader

Comment by suyash | Hacker News Reader

Your loss, it’s a pretty amazing technology and also totally available under friendly open source license.

Evaluating the long term-maintainability of a tool is maybe more important than evaluating if said tool solves a problem. And when dealing with Oracle, your chance of getting royally screwed on licensing as time goes on approaches 100%. So it all depends what kind of time frame you're working on.

In practice, what would be the risk here?

The whole marketing angle behind GraalVM is that it's a drop-in replacement of your JVM. If things go wrong down the road, what stops you from switching back to an OpenJDK distribution from a 3rd party vendor? Nowadays there are enough companies involved in maintaining OpenJDK and Hotspot... including some that aren't exactly friends with Oracle.

I've been burned by far too many subtle bugs caused by real differences in "drop-in" replacements to take that risk again. I've also been burned by too many vendors I thought trustworthy having their priorities change and causing me unnecessary work at bad times.

I work in a very slow moving domain where once we get customers, they tend to stick with a product unless you seriously screw them over. This has moved me to evaluating everything I do on at least a 10-year time horizon.

So in the case of GraalVM, what do I think the risk of Oracle wanting to charge me for every CPU in Amazon's data center is in the next 10 years at the worst possible time to have to drop real work and move everything to OpenJDK? I think it's unacceptably high. YMMV.

Since the faster release cycle that came with Java 9, you really should not architecture anything running on the JVM if you cannot swap the distribution easily. Even if you're on an LTS version from a good vendor (like RHEL), non-trivial patches get backported and can sometimes introduce weird performance regressions.

Isn't that what long term contracts are for? Oracle sign those, they have a whole section of their website related to contracts.

For GraalVM in particular there's no risk because the EE is basically just the open source CE version + more compiler optimizations. So it truly is a drop in replacement.

It's not a drop-in replacement if you want to do native image builds. That can require significant changes to a codebase. That would be wasted effort, at least some of which you'd probably want to reverse, if you later find that GraalVM is not a good option.

Nobody is talking about native images. The article is about big data workloads, specifically Spark.

The discussion has certainly moved on from the original premise of the article.

It extends Java, building in fairly comprehensive language interoperability. Honestly, it's an amazing feature...and also the perfect trap. If you build your code taking advantage of it, you lose compatibility with standard JVMs and you give Oracle leverage over you. And the moment they think they have you, they'll do an about face on their licensing and start charging you for it.

The problem with Java is that there's more to it than just the source code, and Oracle has demonstrated no qualms whatsoever about using essential but non-open-source parts of the Java ecosystem to push people around.

Which parts are "non-open-source" and "essential"?

The TCK is the really big one. It is not Free Software, and it more-or-less necessary to get a license for it in order to successfully maintain your own JVM. Look at what happened with Apache Harmony, for example.

There are also some potential patent encumbrances? I know less about that.

I also don't know for sure if IcedTea is still necessary to get a 100% open build of newer versions of Java (I'm still one of those incorrigible elements who's still on Java 8), but, at least historically, there was an appreciable chunk of the official OpenJDK distribution that was not, in actual fact, open.

> Look at what happened with Apache Harmony, for example.

It died the moment the OpenJDK was released 14 years ago? The issue wasn't the TCK itself, as far as I understand Sun just didn't want to license any Java implementation that could cut into its embedded market and dragged its feet when the community requested an out for the Apache licensed Harmony project. The TCK now seems to be available for any OpenJDK derived implementation[1] in case you want to use official Java trademarks for your implementation.

> I also don't know for sure if IcedTea is still necessary to get a 100% open build of newer versions of Java

I can't actually find anything about IcedTea for any recent OpenJDK, but its wiki page[2] seems to hint at the IcedTea patches were merged back into OpenJDK. Debian and other free software distros also seem fine with distributing current OpenJDK versions instead of reviving gcj to torment their users.

[1]https://en.wikipedia.org/wiki/Technology_Compatibility_Kit#T...

[2] https://en.wikipedia.org/wiki/IcedTea

https://openjdk.java.net/groups/conformance/JckAccess/

The testing suite for the JDK, which allows you to tell if something is compatible to Oracle Java.

Which is frankly a good thing. You wouldn’t want to share the exact questions for a driving license before the test either, would you?

Oracle sells the test kit.

Sure, you wouldn't want to share the answers to the drivers license exam...are you saying that they should sell the answers instead? What the actual fuck?

This is a terrible analogy. We're talking about an automated test suite for verifying that a piece of software conforms to an established specification, not a skills assessment for humans.

Compare it more, perhaps, to housing codes. . . and imagine if the specification of the housing codes were covered by an (at least ostensibly) democratic process, but the actual housing inspectors all worked for one company, and that company also happened to be the biggest player in the construction business. So the inspector therefore had a clear incentive treat outside construction firms with less than complete fairness.

Reply on news.ycombinator.com