3 ms·

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 ven

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.