value type hygiene

[forax at univ-mlv.fr]

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.goetz at oracle.com>
> À: "John Rose" <john.r.rose at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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.