Project Valhalla: A look inside Java's epic refactor | Hacker News Reader

Project Valhalla: A look inside Java's epic refactor

infoworld.com

54 pointsAlupis36 comments

To what degree do these features translate to JVM changes, vs just Java language changes (I know the two are fairly tightly coupled)? Eg will this mean new bytecode/optimizations that could be used to optimize other JVM languages which already have similar features?

Yes, you can read more about the JVM changes in this blog post: https://openjdk.org/projects/valhalla/design-notes/state-of-...

Nice. So for example, it looks like Kotlin already has a nearly identical feature at the language level, which will be optimizable when Valhalla ships: https://github.com/Kotlin/KEEP/blob/master/notes/value-class...

> In the future, in a Valhalla-capable JVM, JVM primitive classes will enable efficient representation of Kotlin value classes with an arbitrary number of underlying fields on JVM.

Except it will mean that the semantics will be observable between JVM, ART, and all remaining Kotlin targets.

> Objects, by contrast, are resistant to this kind of optimization because they have an identity distinct from their value. This is what .equals() tests for: the object’s location in memory.

AFAIK equals() test for equality not identity in Java.

Yeah that looked like a typo (the exact opposite of what they meant to say)

> AFAIK equals() test for equality not identity in Java.

In an ideal world, == would test for equality. In a worse world, equals() would test for equality. But we live in a Java world: Equals() is predefined as an identity check on Objects, and it's up invididual implementations to override that check with something better.

Arguably, equality has no default, meaningful implementation. Object identity is a good default, while data-like objects=records should have the trivial equality in place. But a connection is not equal to any other, even if their internal state is equivalent.

> Arguably, equality has no default, meaningful implementation.

> Object identity is a good default

Is a good fallback, might have been better wording on my part.

The default implementation in Object class tests for identity.

For second I thought this was OpenBSD's OpenSSL Valhalla Rampage

https://opensslrampage.org/

Look what they need to mimic even a fraction of C#'s power :)

C#'s power can always be worked around with JNI, for those that don't have issues with polyglot codebases.

Also lets not forget that Java (even if in a different flavour), powers 80% of mobile phone market, that power alone wasn't enough to keep Windows Phone going, mostly written in C++ anyway (COM/WinRT).

Or the real time Java implementations used by the military, like PTC.

It takes some degree of ignorance to claim that Java can be used in scenarios which require proper structs and object interior pointers.

JNI is an abomination and a cautionary tale for everyone implementing interop facilities into their language.

My ignorance takes me to places you can only wonder about.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

https://www.microej.com/

And to 80% market share in mobile OS market, full of JNI all over the place.

That's a rather damning prospect, that the mobile OS market has.

Luckily, it's not all Android and I will be happily calling Swift directly out of .NET with upcoming interop changes and never have to touch this embarrassment of an API again that is JNI.

At which point better use Swift, a language designed as C, C++ and Objective-C replacement from the ground up.

Not until its performance improves (why yes, I too was surprised to find it being slower than C# in many situations).

As if calling into iOS APIs, some of which written in Swift, via an additional layer would be faster.

By the way, MAUI folks had to rewrite plenty of stuff in Java/Kotlin and Swift, to improve MAUI performance.

The reason why parts of the code had to be rewritten in Java was to work around inherent inadequacy of JNI. This is a sad reality all non-JVM languages have to deal with when targeting Android.

You missed the "and Swift".

If you're mentioning it, I would expect you to know that motivation behind writing Swift helpers was entirely different. Not that it matters in the long run because there will be even better way to do it.

If you don't, then the comment is speculative, pointless and driven by bias.

Regardless, it was done, turns out C# can't do everything on a foreign platform.

The better way is to write Swift, or eventually Objective-C, when iOS is anyway the only OS being targeted, instead of adding complexity layers, just because one fancies C#.

If one were to look under the hood of C#/CLR/dotnet and see just how it does native access, it would be as much of an "abomination" as JNI. The only difference is the tooling provided to C# users is higher level than JNI.

However, unlike the dotnet world, the JVM ecosystem provides numerous ways to do native access, if raw JNI isn't your thing. JNA has been around forever, then there's JNR as well, numerous less-used libraries, and finally Project Panama[1]. Pick the one you like... we get choices.

The dotnet people usually only ever get one option, and believe (falsely) that it's the greatest. A lot like Stockholm Syndrome...

[1] https://openjdk.org/projects/panama/

Declaring and calling a C method in C# is as trivial as

    [LibraryImport("my_library", EntryPoint = "pass_numbers")]
    partial static void PassNumbers(int a, int b, int c);

For AOT compilation, you can even completely statically link[0] it into the binary and annotate with [SuppressGCTransition] - it will be as cheap as a direct call from C++ (although GC transition is just a helper stub call that is barely noticeable on microbenchmarks - 1-2ns difference at throughput).

In fact, you can also do the reverse and AOT-compile C# projects to regular dll/libs which can be called from C, C++, Rust, etc. land with ease:

    [UnmanagedCallersOnly(EntryPoint = "receive_c_string")]
    public unsafe static void ReceiveCString(byte* ptr) { /* impl.. */ }

(there are other aspects that make this a powerful combo like being able to wrap pointers into new Span<byte>(ptr, length)'s and transparently inter-operating with most of the standard library without ever allocating)

Panama may offer better UX but not the one that can match C# and only marginally improves performance over JNI[1] (which is still slow).

[0] https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

[1] https://github.com/Glavo/java-ffi-benchmark

Hmmm, int[] now being a subtype of Object[] is going to cause some odd bugs in code that does lots of reflection - eg. some of the frameworks that doing Rails style magic in Java.

as long as they dont have real first class functions, still behind modern languages

It has had those for a decade now.

The Java 8 additions are sugar for OO interfaces that help doing things similarly as if you had first class functions. But like before, only primitive types and objects are actually first class things.

To mark it as non-first class, you have to provide something it doesn’t support.

Why not abandon the entire thing?

On the contrary - looking at the Java ecosystem I sometimes think, one must be insane not to use Java.

Agree. At this point the JVM ecosystem is pretty mature. Complaining about it is a bit like complaining about Unix. The question isn't whether or not it's good compared to an ideal; the question is whether or not it's good compared to existing alternatives.

The only real alternative is .NET, hence why I use both platforms, :)

Is this mostly adopted what C# has had single the early 2000s? C# always out performed Java for specifically this reason. It is why Unity standardized on C#.

Reply on news.ycombinator.com