Beyond Java

After my Javaland 2023 talk about GraalVM, I was asked how to GraalJS on a stock JDK. At first, I was puzzled. It's possible, but it doesn't make sense. Only it does: since Java 15, OpenJDK ships without a JavaScript engine.

Yes, you can!

GraalJS is available on Maven Central, so nothing stops you from using it:

As always, you need to check the license. You're lucky. GraalJS is distributed under a Universal Permissive License, Version 1.0. The pom.xml even lists the MIT license, but I didn't find any reference to the MIT license outside the pom.xml, so I'm not sure about that.

Unfortunately, GraalJS has been written with the GraalVM compiler in mind, so you end up with a severe performance penalty. That's not always a big deal, but you'll want to add the GraalVM JIT compiler if it is. That, in turn, forces you to start the JVM with additional command-line parameters. Otherwise, the extra compiler isn't recognized. So it's only an option for those already in the DevOps world. At least, I haven't met an operations department yet that allows me to add switches like -XX:+EnableJVMCI.

Read the official GraalVM documentation for a walk-through. Florian Enner's "World beyond Nashorn" is also an interesting read.

Wrapping it up

My recommendation is to migrate to GraalVM. It's a plug-in replacement to your JDK, so I don't expect any problems (but, of course, you never know). You only have to check your license requirements: GraalVM ships under a GPL V2 license with the classpath exception. The Java world has lived with this license for ages, so that won't cause trouble. Still, it's worth noting because most OpenJDKs ship with different, usually more permissive, licenses.

The benefits of using GraalVM are many. Just to name two of them, you can upgrade to the Enterprise Edition to unlock a performance boost of both your Java and your JavaScript code, you get a decent (albeit not perfect) Node.js implementation running on GraalVM, and you can use the native compiler to get predictable performance^[1] and lower memory footprint.

However, if embracing GraalVM isn't an option, there's nothing wrong with using GraalJS on a stock JDK. The two links above guide you through the way.

Adopting server-side rendering pays! Especially if you're running an Angular application on the web. Today, I activated Angular Universal for my blog, and it exceeded my wildest expectations. According to WebPageTest, SSR shaved up to 66% off the rendering time of the first page. That's what counts if you're into SEO. Google rewards fast websites, and it cares mostly about first contact. Once your reader or user is hooked, they tend to be patient. But on first contact, they're shy prey.

Nothing of this is new. So what was stopping me? Well, I'm stuck with a static web server. Even after migrating my blog to AWS, I shied away from using Fargate or EC2 to run my blog. These technologies are cheap if you're running a company, but the monthly $30 fee is heavy for a hobbyist like me. Static web servers are way more affordable. So AWS S3 is my choice. It's an excellent static webserver, especially when combined with Cloudfront.

So let's figure out how to run Angular on a commodity server. I wouldn't call S3 "commodity", but my recipe also works for the average plain-vanilla web hoster.

TL;DR: modern Angular makes it a walk in the park!

Some time ago, I noticed many developers confuse value types and records. Admittedly, that happens to me all the time, too, but these two concepts are fundamentally different. The term "value record" adds to the confusion. Plus, it seems the idea has evolved quite a bit since 2017, when I first heard about it. So I invite you to join my deep dive.

In a nutshell

• Java records are syntaxtic sugar. You use a record to store immutable data. They make programming easier and more expressive, but they're not improving performance. They improve your semantics.
• The value types of project Valhalla enable the compiler to generate faster code. They trade a few features you don't need anyway for improved performance.
• Project Valhalla also plans to introduce a slightly more restricted value type called "primitive classes," allowing for a streamlined memory layout and blurring the difference between primitive types and objects.
• There's also a design pattern called value objects. That's probably where the name comes from, but the value objects of project Valhalla have a different scope and definition. So the design pattern is confusing. Forget about it, at least for the next ten minutes. When I'm talking about value classes, they are a synonym of value types, and value objects are the instances of these value classes.

Records and value types are different concepts, but they aren't opposites. You can have a value record. Well, not now, unfortunately. Both value and primitive types are still under development.

Faster performance and less memory footprint is always exciting. But the real fun is learning why value classes and primitive classes perform better.