They are doing something new in the language -> innovating.

JNI was always the wrong way to do FFI. FFI should require no changes or wrappers in the native code; anything short of that is unnecessary and inefficient. Yet, somehow, in Java land, this is still the norm in 2026?

I'd really want to love Java, but man, it has a long laundry list of warts and a near-zero pace of innovation.

If you include a word like innovating in quotes it typically implies that you're quoting it from the link. It can also signify irony, but in a context like HN where we're discussing a published article, it's often ambiguous.

As for Java, I'd agree that its pace of advance was pretty glacial during the Sun era, but from what I've seen has picked up considerably since the Oracle acquisition and Brian Goetz became architect.

And however bad Java is, it's nothing compared to JavaScript. It takes a decade just to add new a library function, and every new syntax proposal is DOA.

> Yet, somehow, in Java land, this is still the norm in 2026?

FFM (what this article refers to) was released some releases ago. So what is the issue? If you mean what 3rd party libraries use - is that a concern to you? That's like saying there exists legacy code.

> it has a long laundry list of warts

It's such a surprise because you haven't even mentioned 1.

> and a near-zero pace of innovation

Garbage collection? ZGC?

This isn't new or innovating. This is "improving and enriching".

You're unfairly trying to hold making improvements against them.