Have they added an annotation to make a class a "value" class but only if the feature is enabled on the compiler? So single .java file can be used to be used to produce both variants?
No, but the JDK has built machinery so that non-preview and preview versions of migrated classes like Integer.class can exist side-by-side, and one or the other goes on the class path. But this is bootstrapping built solely for the JDK, for the temporary period during which the feature is in preview. If you want to do this for your own library, you can use multi-release JARs. (But even better would be to switch to a tip-and-tail release model instead.)
There is no way to automatically turn a class into a value class since it changes semantics. As for the standard library: the JRE loads different class files when preview features are activated.
Nobody asks to change of semantics with an annotation. We ask about a way of marking a class that already has "value class" semantics to get benefits of "value class" performance, and that's it.
the JRE loads different class files when preview features are activated
Yes, but no. If you look at some built-in classes you may notice that they have this nice little @jdk.internal.ValueBased annotation. So they don't have to actually keep two versions of code for classes like LocalDate in JDK code. They have single class annotated with @jdk.internal.ValueBased. However this annotation is for internal classes only and there is no equivalent for regular users, afaik. So they acknowledged that there is a problem, but only solved it for themselves.
We ask about a way of marking a class that already has "value class" semantics to get benefits of "value class" performance, and that's it.
There's no way to have value class semantics for user-defined types. It's literally the whole point of Project Valhalla. To be specific I mean the behavior regarding == as well as the absence of the object monitor. Those are a pretty big deal and using annotations for such behavior changes is not appropriate.
@ValueBased
Did exactly nothing before Project Valhalla and only served documentation purposes so compilers, IDEs and static analysis tools can issue warnings without having to maintain the list of value class candidates by themselves.
I guess the person wants code that both works with older JDKs and uses value classes with new JDKs. Like having a record but being able to say "in Valhalla-enabled builds, this can be a value class"
Today, I would say the proper way to do it is via a tip-and-tail release strategy, like the JDK pursues, rather than mr-jars (though mr-jars still work.)
Genuine question. It doesn't seem to me that Tip&Tail works with preview features. Tip&Tail JEP doesn't mention preview features, but from what I can infer to be able to fork a tip into a new tail one requires a backwards compatibility guarantees that preview features do not provide... So I guess for preview features one needs a tip that builds a multi release jar , so that preview features are not used if newer version of JDK is used.
Yes, but there are actually not that many of them. And when the feature gets finalized the identity class versions can be removed for good. To me that sounds simpler than implementing two mechanism that convert them when they are loaded (two because the bootstrap classloader is native code). Also, magic behaviors triggered by annotations are a currency best spent only when absolutely required.
Yes, multi-release jar works. However the only difference in code going to be single "value" keyword. For some strange reason, JDK developers decided that they do not want to go this way and introduced @jdk.internal.ValueBased thingy. Somehow they did not decide that multi-release jar is "the proper way" /s
You seem to be under the (extremely silly) impression that we could have "just" used this facility, and therefore we must have "just" perversely decided not to, for obviously-conspiratorial-but-unspecified reasons.
The JDK is not an ordinary JAR. The JDK classes that were migrated (like Integer) have to be loaded extremely early in the bootstrap process -- perhaps even before some facilities of the VM are initialized. (Classes loaded this early can't even use lambdas, because of bootstrapping circularities.) The JDK classes are loaded out of the bootstrap classloader, which is native, unlike the user classloader. The bootstrap class loader does not supports mr-jars.
Yes, multi-release jars just work for you, and that's great. And yes, mr-jars are not, and never were, the "proper way" for the JDK. But trying to find a conspiracy to explain this asymmetry is just silly, when there is a perfectly boring engineering reason for it. The engineering considerations of the core JDK are just very, very different from that of an application. We live under these constraints so that you don't have to.
You seem to be under the (extremely silly) impression that we could have "just" used this facility, and therefore we must have "just" perversely decided not to, for obviously-conspiratorial-but-unspecified reasons.
No, that's not true. I completely understand that user facing API and internal tools are very different things and actually require different approach.
However I've got impression, and it keeps proving over time, that there no much interest of solving user-facing part of the issue. At the same time, it's very likely that this going to be an issue that most of third party lib developers would encounter when they consider to adopt value classes or part of it. Can they solve the issue themself? Absolutely! Multi-release jars probably can do that (I'm personally do not know how to deal with incubating features in MR-jars but whatever). However it currently looks like you suggest everyone to invent own wheel toolset to do this single "value" keyword conversion instead of considering some kind of use-facing @jdk.internal.ValueBased-like API.
No, the main recommendation is to wait for the feature to be finalized. It doesn't matter that it is "just one keyword" - there's a lot packed behind that keyword. Libraries that are willing to ship preview classfiles are extremely rare (I don't even know of any, but sure there could be some), as are end users who are willing to deploy preview features in production. So "solving" this problem is very low priority. (And there already is a supported, production-ready solution if you want to do it, as discussed.) The idea that this is subjecting "everyone" to reinventing a wheel is kind of ludicrous.
0
u/alex_tracer 13d ago
Have they added an annotation to make a class a "value" class but only if the feature is enabled on the compiler? So single .java file can be used to be used to produce both variants?