GraalVM 21.0 Released With Experimental JVM On Truffle

[phoronix]

Phoronix: GraalVM 21.0 Released With Experimental JVM On Truffle

Oracle on Tuesday released GraalVM 21.0 as the latest version of their Java VM/JDK that also supports other languages and modes of execution...

http://www.phoronix.com/scan.php?page=news_item&px=GraalVM-21.0-Released

[Leprechaunius]

Cool. Can we expect a couple of benchmarks?
Also, can anyone recommend a JVM benchmark that simulates real-world reactive programming workloads? Such as context switching, lambdas & functions, etc. I think most of the JVM benchmarking stuff relies heavily on pure computing power.

[uid313]

Is Java 15 better than Java 6? Is it a nice, modern, pleasant to use language?
I used Java 6 (with some parts of 7 and 8) when coding on Android, but then when Kotlin came I moved to that. I didn't think Kotlin was great, but I liked it because it was way more pleasant to use than Java.

[bug77]

Is Java 15 better than Java 6? Is it a nice, modern, pleasant to use language?
I used Java 6 (with some parts of 7 and 8) when coding on Android, but then when Kotlin came I moved to that. I didn't think Kotlin was great, but I liked it because it was way more pleasant to use than Java.

Past Java 8 and lambda expressions, very few changes addressed quality of life. It's miles better now than Java 6, but Kotlin still has more advanced features. I find Kotlin horrible to read, though.

If you could combine Kotlin's coroutines (coming to Java as fibers(?)) with Scala's ability to build DSLs, you could have a hell of a language. If you made that work with native-image, you could even have something cloud-worthy.

[browseria]

Is Java 15 better than Java 6? Is it a nice, modern, pleasant to use language?
I used Java 6 (with some parts of 7 and 8) when coding on Android, but then when Kotlin came I moved to that. I didn't think Kotlin was great, but I liked it because it was way more pleasant to use than Java.

Anything greater than Java 6 provides some nice syntactic sugar, but the development experience with Java is fundamentally unchanged through Java 15, due to strict backwards compatibility requirements (you can still run a Java 1.0 JAR on Java 15 without recompiling). Type erasure is still a thing. Boxing of native types is still way too common. However, there have been some real improvements in each subsequent release that make quite a difference in some aspects: Java 8 introduced Streams and Lambdas making it easier to write Java in a "Functional/LINQ" style. Java 9 introduced modules, which when combined with jlink allows for amazingly small distributables. Combined with the "container awareness" that came in Java 10, it makes Java a decent language to deliver containerized microservices in (as long as you are willing to pay the GC runtime cost). Java 15 introduced records, which are an interesting improvement that makes writing database code and DAOs a little easier, and is one step closer to valhalla which will introduce value types and generic specialization, which should lay the groundwork for finally getting rid of Type Erasure with generics. Java 15 is more pleasant than writing Java 6, but is it better than writing Kotlin? I think that is a value judgement.

See this for a good summary of the changes: https://en.wikipedia.org/wiki/Java_version_history

[bug77]

Anything greater than Java 6 provides some nice syntactic sugar, but the development experience with Java is fundamentally unchanged through Java 15, due to strict backwards compatibility requirements (you can still run a Java 1.0 JAR on Java 15 without recompiling). Type erasure is still a thing. Boxing of native types is still way too common. However, there have been some real improvements in each subsequent release that make quite a difference in some aspects: Java 8 introduced Streams and Lambdas making it easier to write Java in a "Functional/LINQ" style. Java 9 introduced modules, which when combined with jlink allows for amazingly small distributables. Combined with the "container awareness" that came in Java 10, it makes Java a decent language to deliver containerized microservices in (as long as you are willing to pay the GC runtime cost). Java 15 introduced records, which are an interesting improvement that makes writing database code and DAOs a little easier, and is one step closer to valhalla which will introduce value types and generic specialization, which should lay the groundwork for finally getting rid of Type Erasure with generics. Java 15 is more pleasant than writing Java 6, but is it better than writing Kotlin? I think that is a value judgement.

See this for a good summary of the changes: https://en.wikipedia.org/wiki/Java_version_history

1. Modules are nice, but hardly used in practice. Tooling for them sucks.
2. Java still sucks for microservices because of the startup time and JIT. native-image could sorta fix this, but after years of being "experimental" I'm not holding my breath anymore.
3. Just like switch expressions, records are a half-assed effort to catch up to Scala's case classes or Kotlin's data classes.

JVM may still have a future, but my feeling is Java has been losing steam for years. With no sign of recover.

[browseria]

1. Modules are nice, but hardly used in practice. Tooling for them sucks.
2. Java still sucks for microservices because of the startup time and JIT. native-image could sorta fix this, but after years of being "experimental" I'm not holding my breath anymore.
3. Just like switch expressions, records are a half-assed effort to catch up to Scala's case classes or Kotlin's data classes.

JVM may still have a future, but my feeling is Java has been losing steam for years. With no sign of recover.

This is starting to go off topic, but:
1. Hmmm...I've been using modules in production every day for the last 2 years...does that qualify as practice enough? Eclipse and IntelliJ support of modules is excellent/doesn't suck, what tooling are you actually talking about?
2. If you use jlink in conjunction with modules, you would be surprised just how much it cuts down startup time. It's amazing when you can load what you use, rather than a bloated rt.jar most of which is unnecessary - I don't know what you're doing in your microservices, but for us we use less than 10 of the 60-some modules that comprise OpenJDK 15 and not having to load 50-some modules worth of classes and _only_ your code has reduced our startup time to 1/4 what it was before (still in the hundreds of milliseconds, but it gets better with every new JVM, e.g. OpenJDK 15 is about 10% faster than OpenJDK 11, which itself is about 10% faster than OpenJDK 9).
3. Although I can see where someone might get that idea, that really isn't the point of records. It might be helpful to re-read JEP 395 and 360 to get the original intent from the authors themselves (and remember the limitations they have to deal with staying within the bounds of the current Java architecture).

Java can be lean, light and fast which still makes it relevant in a container native deployment, but not if you write Java 15 the same way you did Java 6. Java is growing and changing to meet the challenges of the times, you have to change with it to take advantage, though. I'm not a seer, but I would expect that Java's future will parallel C's future (that is to say, I don't see any need for recovery) and for mostly the same reasons.

[bug77]

This is starting to go off topic, but:
1. Hmmm...I've been using modules in production every day for the last 2 years...does that qualify as practice enough? Eclipse and IntelliJ support of modules is excellent/doesn't suck, what tooling are you actually talking about?
2. If you use jlink in conjunction with modules, you would be surprised just how much it cuts down startup time. It's amazing when you can load what you use, rather than a bloated rt.jar most of which is unnecessary - I don't know what you're doing in your microservices, but for us we use less than 10 of the 60-some modules that comprise OpenJDK 15 and not having to load 50-some modules worth of classes and _only_ your code has reduced our startup time to 1/4 what it was before (still in the hundreds of milliseconds, but it gets better with every new JVM, e.g. OpenJDK 15 is about 10% faster than OpenJDK 11, which itself is about 10% faster than OpenJDK 9).
3. Although I can see where someone might get that idea, that really isn't the point of records. It might be helpful to re-read JEP 395 and 360 to get the original intent from the authors themselves (and remember the limitations they have to deal with staying within the bounds of the current Java architecture).

Java can be lean, light and fast which still makes it relevant in a container native deployment, but not if you write Java 15 the same way you did Java 6. Java is growing and changing to meet the challenges of the times, you have to change with it to take advantage, though. I'm not a seer, but I would expect that Java's future will parallel C's future (that is to say, I don't see any need for recovery) and for mostly the same reasons.

Java still puts food on my table, so I'll try to clarify:
1. While you may be using modules in production, most people don't. It's not a problem with modules, the problem, imho, is ever since modules were introduced, we've only had one LTS release, 11. This leads the the tooling problem I mentioned (probably not the best wording): trying to jlink modules and regular JARs together is messy (or at least it was, last time I tried it). Even Jackson, which incredibly popular, wasn't migrated to modules for years after Java 9 was released.
2. Agree with that, but you still have to deal with JIT: extra memory use and not-so-great-performance from the start. Plus, most people these days use Java together with Spring, which tends to be reflection heavy which also impacts performance (not actually a Java problem, but it happens so often, I think it's worth mentioning).
3. I will look at the JEP more closely.

In short, I agree with you Java today is more cloud friendly than Java 6 was. But imho the endgame is not to beat Java 6, but to rival properly compiled code, that comes with fast startup, best performance and (usually) better memory consumption out of the box.

[browseria]

:
In short, I agree with you Java today is more cloud friendly than Java 6 was. But imho the endgame is not to beat Java 6, but to rival properly compiled code, that comes with fast startup, best performance and (usually) better memory consumption out of the box.

Switching to GraalVM will get you a fast startup time that rivals compiled code (our code starts up in the 10s of milliseconds under Graal), but comes with other tradeoffs because the source is still Java (performance/memory consumption). With all things being equal, I agree with your desired endgame. However, all things are not equal because of the money required to fund development and to maintain operations. This puts it back to the age-old dilemma: do you spend your limited resources optimizing for machine efficiency or for developer efficiency? Any non-GC language is going to be better for a microservice than a GC one from a machine efficiency point of view, the question is do you want to spend your resources on the more expensive developers needed to successfully pull that off, or would you rather rely on a Java cattle-call? Picking Java means you're going to pay more for the actual running of the service over its lifetime, the question then becomes what percentage of that vs. the additional startup cost to get it written in another language. For a good percentage of services (perhaps a majority), the development costs are more important than the execution costs. Unless your microservice requires Google-like scalability, there are more than enough options with Java that make it "good enough" even though there are gains to be made operationally going another way.

Regarding JPMS, I expect this to change once Java 8 is EOL and the new floor is Java 17. Many third party dependencies like Jackson still have to cater to people running Java 7, Java 6, etc. which hampers the speed at which they can adopt JPMS. When the minimum supported Java version they support also supports JPMS, the reasons for adopting modules become more compelling. It will happen, it will just take a little time...check again in 2025!

Regarding Spring/Reflection: it is a pox! Look at Micronaut - "Spring"-like with ZERO reflection.

[bug77]

browseria Yeah, that's what I was getting at. GraalVM is not required for good Java performance, you can get that with Micronaut or Quarkus. The trouble is, Micronaut or Quarkus are more like skunkworks in big companies that use Java

About efficiency, there's always Python. Instant startup, not so great performance and development speed that you can only get in Java if you use Quarkus+hot compilation. Go is also a great choice. Same development speed as Pyhton (it's not just save and run, but the compiler is really fast), properly compiled, so that distribution is a piece of cake. Still GCed, which may bite you here and there. There's also Rust. I've been hearing a lot of good thing about Nim... All the fun stuff seems to be happening elsewhere, with Java left to play catch up. And losing at that.

As for EOLing Java 8, we still have Java 6 in production (because, why not?), so I wouldn't bet on that either. A shame, really, because having a way to expose only what you want to expose would both let you change internal dependencies at will and let anyone learning about your module access only what they're supposed to.
I don't think catering to older Java versions is the issue here. Older versions will just ignore the module.info and treat the JAR as they do today.

Btw, thanks for staying constructive, even if we're way off-topic now.