I agree with Brian that having spurious NPEs will not help. I think reporting a NPE is nefarious here, the semantics of a NPE is too engraved in the Java dev heads, we should report an incompatible change class error or exactly a subtype like by example VMHeroicEffortToProvideValueTypeMigrationFromAReferenceTypeFailError saying which class see the value type as a reference type (in order to be re-compiled).
Rémi ----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "John Rose" <john.r.r...@oracle.com>, "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Vendredi 11 Mai 2018 19:13:19 > Objet: Re: value type hygiene > I get the motivation for this. FTR, though, I am pretty skeptical that > such unexpected and hard-to-explain NPEs won't show up more frequently > than the ignorability threshold, and the result will be a perception > that Java is unstable. (Remember, people mix and match with libraries > that have been compiled at all different language levels.) > > On 5/10/2018 9:36 PM, John Rose wrote: >> >> Again, JVM could go the extra mile to make this problem >> disappear, by re-organizing the calling sequence of the override >> tree as soon as the first legacy method shows up. For simplicity >> I'd rather exclude this tactic until forced by experience to add it. >> It seems like a heroic optimization to me, seldom used and likely >> to be buggy. It also seems to spoil the whole performance party > > when one bad actor shows up, which looks dubious to me.
