Hacker News Reader

Comment by legobmw99 | Hacker News Reader

Java and C# seem to have actually gotten the idea of multiple implementations correct, in the sense that I have never needed to worry about the specific runtime being used as long as I get my language version correct. I have basically never seen a C/C++ program of more than a few hundred lines that doesn’t include something like #ifdef WIN32 …

View on HN

Well, there's Android... and Unity, which as I recall is stuck on an old version of C# and its own way of doing things. I also had the interesting experience of working with OSGI at work a couple of years.

And Meadow, and Capcom, and Gotdot 3,

Is there more than one Java implementation that is usable? All I can find are obsolete products that never got very far.

Eclipse OpenJ9 (previously IBM J9) is in active development and supports Java 21.

Here are a few Java implementations that I've used recently.

- My Android phone

- OpenJDK on my laptop

- leJOS for a university robotics course to run on Lego robots

- Smart cards, I have a couple in my wallet

Perhaps I'd call the Lego robot stuff obsolete, certainly not the Android userspace or smart cards though.

Your Android phone and the latest Java share very little commonality. It only recently supports Java 11 which is 5 years old at this point. The other non-OpenJDK implementations you mentioned are much more niche (I imagine the smart cards run JavaCard which is still probably going to be running an OpenJDK offshoot).

Java 17 LTS is supported from Android 12 onwards.

PTC, Aicas, microEJ, OpenJ9, Azul, GraalVM are a couple of alternative JVM implementations.

Again. I’m not claiming that alternative implementations don’t exist, just that they’re not particularly common/popular compared with OpenJDK/Oracle (which is largely the same codebase). Android is the only alternative implementation with serious adoption and it lags quite heavily.

BTW GraalVM is based on OpenJDK so I don’t really understand your point there. It’s not a ground-up reimplementation of the spec.

GraalVM uses another complete infrastructure, JIT and GC compilers, which affect runtime execution, and existing tooling.

Doesn't matter how popular they are, they exist because there is a business need, and several people are willing to pay for them, in some cases lots of money bags, because they fulfill needs not available in OpenJDK.

I don't think what you're describing here is accurate re: GraalVM. GraalVM is Hotspot but with C1/C2 not being used, using a generic compiler interface to call out to Graal instead AFAIK.

Only if you are describing the plugable OpenJDK interfaces for GraalVM, that have been removed a couple of releases after being introduced, as almost no one used them.

I have been following GraalVM since it started as MaximeVM on Sun Research Labs.

Who said anything about the latest Java. Since Java has versioned specs, platform X can support one version, and you can target it based on that information even if other versions come out and get supported by other platforms.

For example C89 and C99 are pretty old, and modern C has a lot that is different from them. But they still get targeted and deployed, and enjoy a decent following. Because even in 2024, you can write a new C89 compiler and people's existing and new C89 code will compile on it if you implement it right.

But as a developer I do want to use (some of) the latest features as soon as they become available. That's why most of my crates have an N-2 stable version policy.

And since Rust does a release every 6 weeks, we’re talking a ~4 month lag. That’s unheard of for C/C++.

It is the sort of thing that people aimed for in the 90s, when there was more velocity in c and c++. If rust lives long enough the rate of change will also slow down.

In the 90s if you wanted new features you had to pay for them.

Reply on news.ycombinator.com