4 ms·

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

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.

blacktriangle 5y ago
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.
- hocuspocus 5y ago
  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.
- native_samples 5y ago
  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.
antonvs 5y ago
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.
- hocuspocus 5y ago
  Nobody is talking about native images. The article is about big data workloads, specifically Spark.
  - pritambaral 5y ago
    The discussion has certainly moved on from the original premise of the article.
darksaints 5y ago
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.

blacktriangle 5y ago

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.

hocuspocus 5y ago
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.
native_samples 5y ago
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.

antonvs 5y ago

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.

hocuspocus 5y ago
Nobody is talking about native images. The article is about big data workloads, specifically Spark.
- pritambaral 5y ago
  The discussion has certainly moved on from the original premise of the article.

darksaints 5y ago

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.