<div dir="ltr">Optional.val? Do you mean that the reference-favoring primitive class still exists?<br><div>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.<br></div><div>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.<br></div><div>Is my understanding wrong?<br></div><div><br></div><div>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.<br></div><div>I mean, the code containing null polling will be unusable (the original words in the JEP draft). <br></div><div>If my understanding is correct, it means that it will destroy the code that has not solved the null polling, right?<br></div><div><br></div><div>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, </div><div>they often don't get the attention they deserve, thus becoming an obstacle to migration.</div><div>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. </div><div>Even a widely used library like Jackson will make mistakes. Some of these problems could have been avoided.<br></div><div><br></div><div>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.</div><div>Therefore, I need to use translation software, which may cause deviation in my meaning. <br></div><div>I apologize for the inconvenience this has caused you.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 1, 2022 at 10:50 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 12/1/2022 6:46 AM, Glavo wrote:<br>
> I haven't read the description of binary compatibility between Q type <br>
> and L type anywhere.<br>
> I have made several attempts on LW4, but the attempt to change the L <br>
> type to Q type in the API method signature always causes <br>
> NoSuchMethodError to be thrown when calling it.<br>
> Of course, I know that the implementation of the primitive class is <br>
> still incomplete.<br>
> However, I haven't seen any description of the migration scheme so <br>
> far, so I'm worried about it.<br>
<br>
In the current framing, if you have a class "Optional" which is <br>
currently an identity class (therefore translated to LOptional), and you <br>
migrate it to a value / primitive class, the language-level type <br>
"Optional" still translates to LOptional (though without identity, so it <br>
can be more heavily optimized.)  Existing APIs that are full of Optional <br>
will still work fine, because all source utterances of "Optional" and <br>
all binary utterances of "LOptional" still mean what they meant before <br>
(minus identity.)  This is source- and binary- compatible.<br>
<br>
If you go and change all your Optional to Optional.val in your APIs <br>
(e.g., public methods), now you've made a binary-incompatible change, <br>
which might be a problem in the face of separate compilation.  (If you <br>
do this for internal APIs, such as a private field, no problem, because <br>
you're recompiling all the code that depends on the translation.)  But <br>
this is no different than *you* changing an API from `m(Integer)` to <br>
`m(int)`, so I don't see why you'd expect that was a compatible change.<br>
<br>
Simply migrating a class from identity to value will not break linkage <br>
of uses of that type.<br>
<br>
> I'm very surprised that you have questions about Valhalla breaking <br>
> compatibility. Am I misunderstanding JEP draft 8261529?<br>
> What I've learned from reading this draft is that Universal Generics <br>
> will cause a large portion of existing code to have null pollution <br>
> warnings and be completely broken in the future.<br>
<br>
Hyperbolic phrases like "completely broken" are not helpful (even worse <br>
when they are extrapolations from incorrect assumptions.)<br>
<br>
> When we talk about migration, a lot of times it's not Java 8 to Java <br>
> 25 (assuming we can see Valhalla in Java 25), and often what we need <br>
> is to migrate from Java 8 to Java 8:<br>
> We want the migrated code to continue to compile on Java 8, but at the <br>
> same time to fit Java 25 as perfectly as possible.<br>
> This is a fairly common requirement, since most third-party libraries <br>
> distributed through maven repositories want to work on as many Java <br>
> versions as possible.<br>
<br>
Do you really think we need to be lectured on the value migration <br>
compatibility?<br>
<br>
<br>
</blockquote></div>