Interesting, thanks. I know the entire industry is built around Hadoop and the JVM right now (with some Python), but I'm hoping the pendulum will swing in a different direction soon.
The first EA release for value types support is out now.
I firmly believe in the end tracing GC with value types and local ownership, like D, Swift and C# are pursuing will win, at least in the realm of userspace programming.
If Java can have struct access into native memory (without the presently complicated API [1]) that would open a lot of doors and get it to near feature parity with the CLR.
[1] https://docs.oracle.com/javase/6/docs/api/java/nio/ByteBuffe...
https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-Ju...
And follow the links from there, including the Wiki page describing the EA release, unfortunately my submission did not gather too much uptake.
It is taking all this this time because the team wants pre-value types world jars to keep running unmodified on the new world, not an easy engineering task.
I would like to see the industry move away from the JVM to less memory-hungry, AOT-compiled languages. Too much of the Hadoop world simply assumes that you'll be using a JVM language, and don't provide non-JVM APIs at all. It's been a while since I looked, but I think Apex and Flink were basically useless if you didn't use a JVM language or Python.
Of all the Apache projects related to Hadoop, I believe Beam is the only one that has Go support (for implementing processing logic), for example.