<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On May 14, 2018, at 4:13 PM, Remi Forax <<a href="mailto:forax@univ-mlv.fr" class="">forax@univ-mlv.fr</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div style="font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I think i prefer a declaration site annotation like @ValueBasedClass to a use site annotation ValueRef<V>.<br class=""></div></div></blockquote><div><br class=""></div><div><div>In case it's not clear what I am proposing, I am not weighing in on language</div></div><div>notations, but rather on VM structures in the context of the L-world experiment:</div><div><br class=""></div><div> - The L-world JVM should *not* be asked to invent two new runtime types for every VT.</div><div> - Nullable references to value types in new code should be expressed using reference types.</div><div> - In bytecodes, such nullable references can be Object or a new VT-specific interface or a mix of both.</div><div><br class=""></div><div>In source code, I really don't care how nullability is expressed:  annotation?</div><div>keyword?  punctuation?  Java 5 generic?  etc.</div><div><br class=""></div><div>In source code there is the *option* to use interface ValueRef<VT> to denote</div><div>"nullable ref to VT", erased to "LValueRef;" in the JVM.  I think that would be a</div><div>clever use of erased static types, and a thrifty re-use of existing Java 5 language</div><div>features.</div><div><br class=""></div><div>(Surely a bespoke syntax would be more concise; that's fine, but when it boils</div><div>down to a JVM descriptor, please let it be non-nullable "LVT;" or else a reference</div><div>type like "Ljava/lang/Object;" or "Ljava/lang/ValueMumble;", not a new kind of</div><div>descriptor or an MVT-style mangled name.  I am claiming we don't need that</div><div>and don't want to pay for it.  Please prove me wrong, if I am wrong, by</div><div>experiment with a restricted L-world JVM running real code, and not by positing</div><div>various unlikely compatibility puzzles.)</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">For me a value based class, if you want to be as compatible as possible, is a reference type (so 'L') that behave like a value type at runtime, so the JIT can see it has a value type at runtime and can unbox it at will and buffer/box it before calling a method at the horizon of the inlining blob.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br data-mce-bogus="1" class=""></div><div style="font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">So as a library designer, i can choose to either replace a class by a real value type and it will fail if null is present or as a value based class if i value (sorry !) the backward compatibility more than the performance.</div></div></blockquote><div><br class=""></div>(Now I'll respond to your suggestion of notation.)</div><div><br class=""></div><div><div>The annotation approach you suggest makes it nice and easy to sneak an</div><div>annotation next to a use of a type.  That's appealing.  It's also sneaky since</div><div>it slightly modifies the behavior of the problem (NPE vs. pass).  The downside</div><div>of the annotation is that, unless coupled with an annotation-sensitive translation</div><div>strategy, the JVM has to mine through annotations to find out which descriptor</div><div>components are nullable and which are not.  The ValueTypes attribute is our</div><div>best proposal yet for a way to pass the necessary information through to</div><div>the JVM; surely you don't expect the JVM to turn around and look at</div><div>type annotations in addition?</div><div><br class=""></div><div>I prefer ValueRef<VT> as a way to express nullability (instead of a type annotation)</div><div>because it carries the same information, but all in the (static) type system.</div><div>After erasure, the JVM can inspect the descriptor directly and immediately</div><div>see whether the type is nullable or not.  (ValueRef is *not* in the ValueTypes</div><div>table.  Simple!)</div><div><br class=""></div><div><div><div>You could also drive the translation strategy to perform surgery on descriptor</div><div>elements annotated by @ValueBasedClass.  Thus, an argument or return</div><div>type of type VT with that annotation would be adjusted by the translation</div><div>strategy to descriptor Object (erased from VT-or-null) or a suitable interface</div><div>(such as ValueRef).  That is an erasure, and so will disturb overloading rules</div><div>and other things.</div><div><br class=""></div><div>Or we could push the annotation down into the descriptor syntax as a modifier.</div><div>That's Q-world, with its own complementary problems we are trying to avoid</div><div>by running the L-world experiment.</div><div><br class=""></div><div>One problem that shows up both at JVM and language level is that any</div><div>special mechanisms we invent to grease the skids of migration will be</div><div>with us forever, even after migration is a distant memory.  I'd want a</div><div>story for deprecating and removing API points that need the extra</div><div>grease of @ValueBasedClass.  Eventually @ValueBasedClass itself</div><div>should be deprecated.</div><div><br class=""></div></div></div><blockquote type="cite" class=""><div class=""><div style="font-family: arial, helvetica, sans-serif; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Note that even if we solve the null issue when a reference type is changed to a value type and i think it's not something we should focus on, there is still the problem of the identity, so transforming a reference to a value type will never be 100% compatible.<span class="Apple-converted-space"> </span></div></div></blockquote><br class=""></div><div>+100.  Trying to cleverly solve every last compatibility problem will</div><div>freeze us into inaction.</div><div><br class=""></div><div>— John</div></body></html>