JEP 401: Value Objects (Preview) merged to OpenJDK master

The idea is that instead of controlling memory layout and referencing directly, you communicate your intent: do you care about this value's identity or not? Do you need atomicity or not? Do you need nullability or not? Once the intent is clear, the compiler is free to choose the most appropriate and efficient layout for the particular value at the particular use site. In other words, you say what semantics you're interested in rather than how to implement them at the lowest level.

This opens up optimisation opportunities that are lost when the programmer directly controls the representation rather than the intent. E.g. in other languages you may say whether you want to pass some value by reference or by value. Here the compiler is free to say, well, if identity and nullability are not needed here, I can either pass by value or by reference, and I'll do whichever is more efficient.

And by the way, your point about early misdesign (whether it applies here or not) also inverts the desired state. Every language makes decisions that will be suboptimal in the environment some time later, and Java certainly has its share (its mutability and nullability default; how it treats serialisation). Rust, for example, was first designed twenty years ago, and some of its fundamental decisions reflect the state of the world at that time (it went all-in on some C++ premises that seemed fine 20 years ago). But since important codebases often outlast the outdatendness of early language decisions (your OS and your browser are running some >30yo code and/or affected by >30yo design decisions), one of the things most important in a language isn't the decisions it makes early on - some will prove "wrong" while your codebase is still alive and kicking - but how well it adapts and evolves. So when you pick a language for an important project today, the language's current state will end up mattering less than how the language evolves in the future. The question asked isn't "will I like this decision today?" but "will I regret this decision ten years from now?" Java is one of the languages with the lowest "regret factor", possibly lowest of them all.

Nothing, absolutely nothing about the design is a compromise that would detract from the project if it was for any other language.

You could judge them for bringing “complexity to an easy topic” but it really is far from that and the idea of a value type being a distinct dichotomy from an object is just a convenient tradition.

The push for immutability and value-ness has been going on for a long time and the motivation of the project was to bring performance benefits that align with semantic statements about the underlying data type. Which is of course a more nuanced take than “go value, go faster”.

They added so much new syntax to C# to the point it really is starting to feel like C++++ whereas Java has modernized itself without massively expanding its syntax and modifiers.

On the other hand I have used Quarkus which was great until it wasn’t because a certain http feature wasn’t supported or we needed integration with an unsupported database. In enterprise that is enough reason to just choose for the batteries included option and lift along on improvements of the main framework.

I'm back on Spring for work reasons but use it for all my side-projects.

And yet a lot of enterprises have done without in other languages.

When I worked at a BigCo [1], our project was a big monorepo in Java which had 60,000 folders, and I don't remember how many files. It was decidedly no fun to work on, because everything was spread across a million files and so doing anything required sifting through dozens or even hundreds of files. I hated it.

I've worked on giant projects since then, but they've been written in more modern Java and they are less painful.

[1] It's not hard to find the specific one through my history but I politely ask you do not post it in reply to this post.

I've written plugin systems for stuff I've worked on, and it didn't require nearly the same level of verbosity. Granted, I usually have done this with sockets instead of directly using JVM and reflection. To each their own, but I like using sockets (usually ZeroMQ) for this stuff because then it's completely language independent.

Even if I granted that you needed to use all this factory and builder glue stuff, I don't agree with the typical Java developer's strategy of breaking things up across a million files, which Java at least greatly encourages.

It's more that it's easy to write code that links directly into the game. Easy to do because you can decompile them and make changes easily without having source code. Sure, Minecraft was obfuscated for a long time, but people put a lot of effort into deobfuscation and obfuscation removes a lot less than native compilation.

(You also don't need an official modding API this way)

I think that, with all things on the table, backwards compatibility, a spec and, where things are broken things are signaled should be the standard for enterprise grade non-toy apps.

Of course, breaking something should be kept to the minimum.

That is why I keep using C++ and, if I have to do backend in the future for webs, I will probably choose Java over C#: stable, multi-vendor, will work in 10 years, stable.

C++ is very different since it is native.

Java is a VM.

This affects lots of decisions in weird ways.

But in essence both commit to backwards stability at the end.

C++ goes for performance, JVM for a more full-featured bytecode vm, etc. but still.

https://www.keycdn.com/support/difference-between-java-and-j...

The cache can be extended on startup with env var `java.lang.Integer.IntegerCache.high `

https://github.com/openjdk/jdk/blob/cc278dbb8a1ca0754d584270...

https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...

This is the strength of Valhalla. Instead of a binary object/value choice you have different levels of semantic guarantees that will give you better performance characteristics, depending on what your type will be able to give up.

You can have tearability for a complex/quaternion number without problem. But if you have something such as a Range-type class, that gets more problematic because cross-field constraints can be violated.

Basically JEP401 guarantees that just adding "value" to the class won't change behaviour, which also means that you are not allowed to see object tearing, which requires atomic operations on the field.

Relaxing that would break safe publication rules, at least for Java.

This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.

It will likely require you poke in the `jdk.internal` package space.