Replace the primitive class with a more general null safety?

[Brian Goetz]

On 12/1/2022 6:46 AM, Glavo wrote:
> I haven't read the description of binary compatibility between Q type 
> and L type anywhere.
> I have made several attempts on LW4, but the attempt to change the L 
> type to Q type in the API method signature always causes 
> NoSuchMethodError to be thrown when calling it.
> Of course, I know that the implementation of the primitive class is 
> still incomplete.
> However, I haven't seen any description of the migration scheme so 
> far, so I'm worried about it.

In the current framing, if you have a class "Optional" which is 
currently an identity class (therefore translated to LOptional), and you 
migrate it to a value / primitive class, the language-level type 
"Optional" still translates to LOptional (though without identity, so it 
can be more heavily optimized.)  Existing APIs that are full of Optional 
will still work fine, because all source utterances of "Optional" and 
all binary utterances of "LOptional" still mean what they meant before 
(minus identity.)  This is source- and binary- compatible.

If you go and change all your Optional to Optional.val in your APIs 
(e.g., public methods), now you've made a binary-incompatible change, 
which might be a problem in the face of separate compilation.  (If you 
do this for internal APIs, such as a private field, no problem, because 
you're recompiling all the code that depends on the translation.)  But 
this is no different than *you* changing an API from `m(Integer)` to 
`m(int)`, so I don't see why you'd expect that was a compatible change.

Simply migrating a class from identity to value will not break linkage 
of uses of that type.

> I'm very surprised that you have questions about Valhalla breaking 
> compatibility. Am I misunderstanding JEP draft 8261529?
> What I've learned from reading this draft is that Universal Generics 
> will cause a large portion of existing code to have null pollution 
> warnings and be completely broken in the future.

Hyperbolic phrases like "completely broken" are not helpful (even worse 
when they are extrapolations from incorrect assumptions.)

> When we talk about migration, a lot of times it's not Java 8 to Java 
> 25 (assuming we can see Valhalla in Java 25), and often what we need 
> is to migrate from Java 8 to Java 8:
> We want the migrated code to continue to compile on Java 8, but at the 
> same time to fit Java 25 as perfectly as possible.
> This is a fairly common requirement, since most third-party libraries 
> distributed through maven repositories want to work on as many Java 
> versions as possible.

Do you really think we need to be lectured on the value migration 
compatibility?