Oracle sweetens Java SE subscriptions with a spoonful of free ‘GraalVM’ runtime said to significantly speed Java Oracle has sweetened its Java SE subscriptions by tossing in a free entitlement to use GraalVM, a new universal virtual machine that Big Red says runs just about anything faster, anywhere. Reader: The Register confesses GraalVM had escaped our attention until today. The project’s GitHub page tells us it’s “a universal virtual …
Soon "free" will become a convoluted, impossible to understand licensing model.
Ahh it's free for THIS service but if you mix it with THAT service, then it is now longer free unless THAT service us using OUR version of that service, then its 50%, unless OUR service is used conjunction with THEIR service than that's 125%.
In fact just give us 75% of your turnover, just to be on the safe side.
GraalVM is licensed under "version 2 of the GNU General Public License with the “Classpath” Exception, which are the same terms as for Java" (from the FAQ). Oracle could of course change the license starting from some newer version, but if GraalVM has enough interested users at that point, it will just trigger a fork of the last GPL-licensed version.
This gives it a kind of vaccination against unreasonable licensing.
Java SE is not free - it has a commercial licence that "permits personal use, development, testing, prototyping, demonstrating and some other uses at no cost."
This article is muddying the water.
If GraalVM requires Java SE, then it's not free. But if GraalVM is GPL and runs independently of Java SE, then saying that "might just give those users and developers an on-ramp that keeps Java SE relevant" makes no sense.
Yes, the water is muddy. I guess Java SE and the attached GraalVM are Oracle's productised binaries, for which they charge. You (or someone else, like AdoptOpenJDK) can put together a somewhat equivalent system from the GPL'd sources (minus Oracle's blessing and branding).
The .net strategy has always been, multi-language. The only reason the CLR does not natively support Java is legal reasons (IKVM adds JVM support.
The reason ECMAScript and Python don't work so well on a "foreign" runtime is dynamic code and it's metadata for eval() performance.
Interoperability between Java and non managed code (C/C++) is still problematic because of the rubish JNI
When will the speed of light stop this monster?
A small snail wearing an Arsenal logo gets beaten up by a tortoise with Liverpool insignia. At home, the big brother - an ardent Arsenal fan - shouts:
"Describe the tortoise and do not leave out any details. I'm gonna pay that bastard a visit and beat the living shit out of it!”
Small snail: "Dunno ... it all happened so fast."
JVMs are not my field of expertise, but the last time I hit an issue with Hotspot an Oracle support engineer suggested we switch to Graal. I get the impression Hotspot is getting a bit long in the tooth. No performance gains noted, and believe me we are always looking for them. But it did fix the problem, so we've been running Graal as our primary VM now and have done for a couple of years.
Graal is a very elegant concept and looks well executed too, at least on the surface (ie I read the docs and liked what I saw). We work with Java and JS in the same VM, and being able to integrate other languages, in particular LLVM-based ones, has me interested. I'm surprised Oracle hasn't made more of a big deal of it.
@ _LC_ - yes, clearly execution speed is all that matters, which is why the bulk of the world's development is done in assembly.
A JIT has the advantage that it can inline virtual methods, skip call stack formalities, use thread/stack scoped heaps, relocate semaphores, and remove bounds checking. These optimizations are only safe because there's a mechanism to remove or repair them as conditions change. Since the early days, Java has provided features that depend on these tricks existing. Past static pre-compilers have not worked well.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
