Replace the primitive class with a more general null safety?

[Glavo]

Optional.val? Do you mean that the reference-favoring primitive class still
exists?
I know it used to exist in JEP 401, but after the value class JEP draft
came out, the description of reference-favoring primitive class was removed.
This makes me think that Valhalla wants the identity class to be migrated
to the value class and not allowed to migrate to the primitive class.
Is my understanding wrong?

I'm sorry for the misuse of words. I can't understand these English words
accurately, because my English is very poor, so I use Google Translate to
write the email.
I mean, the code containing null polling will be unusable (the original
words in the JEP draft).
If my understanding is correct, it means that it will destroy the code that
has not solved the null polling, right?

For migration related matters, I don't think you need me to introduce
these, but I just remind you that although they are very basic,
they often don't get the attention they deserve, thus becoming an obstacle
to migration.
This has happened many times. Like Jigsaw and JavaFX 9, they bring extra
difficulties to all versions that support Java 8+at the same time.
Even a widely used library like Jackson will make mistakes. Some of these
problems could have been avoided.

Then, I apologize again for my English level. My mother tongue is not
English. I can only read English slowly. Writing is difficult for me.
Therefore, I need to use translation software, which may cause deviation in
my meaning.
I apologize for the inconvenience this has caused you.



On Thu, Dec 1, 2022 at 10:50 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> 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?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20221202/4b2a6b89/attachment.htm>