I don't think that's really the case anymore. You have to separate three things:
1. Using the JVM for its capabilities, like the JITC and GC engines, which are very powerful.
2. Using the JVM for Java interop.
3. Using the JVM for generic cross-language interop.
The nice thing about the JVM especially now with Graal/Truffle is it lets you explore and choose almost any point on the spectrum between "we're totally alien and the JVM is just our runtime" and Kotlin-esque "we are basically Java v2 with perfect interop". Modern JVMs are capable of running languages as diverse as Haskell, JavaScript, Kotlin, Ruby, WebAssembly, LLVM bitcode etc. Obviously if you're coding in C or Rust and running it on the JVM via Sulong, your interop is going to be limited to creating objects and invoking simple functions on them. If you're in Ruby or Python your interop gets better: you can expect automatic translation of things like Java-world collections to a vaguely native-language like collection via the Polyglot interop layer. And if you're Kotlin then you don't even create your own collections at all, just use the JDK standard library.
The point is, you don't have to use the Java bytecode type system to interop with Java or other languages anymore. Graal has fixed that. Your language can have any arbitrary semantics and it will still be JIT compiled, GCd and it can still call into other languages. The closeness of the type system is now a choice you make that trades off ease of use of Java libraries vs whatever divergence you want to have.
> Modern JVMs are capable of running languages as diverse as Haskell, JavaScript, Kotlin, Ruby, WebAssembly, LLVM bitcode etc.
As long as you don't mind either poor performance, or paying Oracle a bunch of money for good performance.
What all the fancy marketing takes pains not to say directly is that GraalVM is shareware. The open source version is just a basic version with some teaser features to get you interested, and, in classic Oracle fashion, the price of the full version is, "If you have to ask, you can't afford it."
I have no real objection to that model for other products, like BerkeleyDB. But I wouldn't want to build an entire open source ecosystem on a foundation like that.
The open source version of Graal does not have poor performance, by any means. It's more or less as good as regular Java, or better for some languages, but it's not really worse except perhaps on a few specific microbenchmarks.
Moreover, GraalVM is open source. Please don't try and redefine basic terms, as otherwise by your logic Linux would be shareware because Red Hat sell a better version of it, Android would be shareware, Chromium would be shareware etc. Making an open source product and selling a better version that isn't is perfectly legit. If you don't believe that, how do you envision platforms be funded?
As for the pricing, it is or was on their online shop. You could buy it with a credit card. Seems they have a problem with their store right now, but I've seen public price lists in the past. It's expensive but not at all "if you have to ask you can't afford it".
From what I've seen, it's only the small benchmarks where the open source version of Graal is on par with regular Java, because their short run-time ensures that all the bits that give HotSpot its name don't have a chance to kick in.
I think my point stands regardless of any quibbling about terminology. I've got no objection to some sort of free-however-you-capitalize-it-but-with-paid-premium-features model in general. But baking such a business model into something as fundamental as a cross-platform ABI standard sets a really bad precedent. Having lived through the late '90s, that sort of thing immediately brings the phrase, "embrace, extend, extinguish," to mind.
I'm glad to hear they've started publishing a sticker price. My memory isn't what it used to be, but I believe that wasn't the case when I evaluated it.
Are you mixing up Graal the JIT compiler with Native Image the tool that spits out ahead-of-time compiled executables? When I say "Graal" I mean the JIT compiler that can run on regular HotSpot and is just an ordinary Java JITC implemented in Java.
You have to distinguish between technical standards and implementations.
JVM bytecode is a technical standard for a portable, cross platform, strongly typed ABI. Anyone can implement it based on the docs.
Truffle is an open source API with a clear specification for creating interpreters. Anyone can implement it based on the docs, although there's no reason to do so given its permissive licensing.
Beyond that it's all implementation: the Graal JIT recognises when it's compiling Truffle interpreters and does it in a fast way, but it doesn't have to and Truffle interpreters can run on any JVM including those that pre-date Truffle's own existence. They just won't be as fast. GraalVM EE is a for-pay version that does an even better job, well beyond state of the art, but the open source free version is no slouch and Scala code can go faster by e.g. 20% or more even with the open source version.
There is ALSO the native-image tool that compiles things to native code ahead of time. Many people use the word Graal to mean this, because it's the most eye-catching thing in the suite, but that's not correct. It's called either native-image or SubstrateVM. The open source version of this produces code which is slower than regular HotSpot runs but has no warmup time and starts instantly. The speed drop is due to losing profile guided and speculative optimisations, it's not a pricing issue. The EE version of native-image that you pay for has various other features like the ability to gather profiles using HotSpot and then use them when compiling to win back some of the speed, but not all of it - you can't really beat Graal JITC on HotSpot for peak performance. The EE version also has some other useful features for security and sandboxing.
In other words, the Java/Oracle guys seem to be doing exactly what you'd want to see: there are standards, specifications and then implementations - all clearly separated. There are open source implementations, and better ones with support contracts that fund the development of the whole shebang.
1. Using the JVM for its capabilities, like the JITC and GC engines, which are very powerful.
2. Using the JVM for Java interop.
3. Using the JVM for generic cross-language interop.
The nice thing about the JVM especially now with Graal/Truffle is it lets you explore and choose almost any point on the spectrum between "we're totally alien and the JVM is just our runtime" and Kotlin-esque "we are basically Java v2 with perfect interop". Modern JVMs are capable of running languages as diverse as Haskell, JavaScript, Kotlin, Ruby, WebAssembly, LLVM bitcode etc. Obviously if you're coding in C or Rust and running it on the JVM via Sulong, your interop is going to be limited to creating objects and invoking simple functions on them. If you're in Ruby or Python your interop gets better: you can expect automatic translation of things like Java-world collections to a vaguely native-language like collection via the Polyglot interop layer. And if you're Kotlin then you don't even create your own collections at all, just use the JDK standard library.
The point is, you don't have to use the Java bytecode type system to interop with Java or other languages anymore. Graal has fixed that. Your language can have any arbitrary semantics and it will still be JIT compiled, GCd and it can still call into other languages. The closeness of the type system is now a choice you make that trades off ease of use of Java libraries vs whatever divergence you want to have.