valhalla-spec-comments post from jackammo77 at gmail.com requires approval

[Remi Forax]

Correctly if i'm wrong but it doesn't solve the issue of an old code* doing a synchronized on an object taken as argument of a method.

And it's worst because new code will have to be updated to take a NativeSynchronizable as parameter which is not a backward compatible change. 

Rémi
* all the existing Java codes at the time i'm writing this email

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> À: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 20 Février 2019 13:21:22
> Objet: Re: valhalla-spec-comments post from jackammo77 at gmail.com requires approval

> On Wed, 20 Feb 2019 at 01:05, John Rose <john.r.rose at oracle.com> wrote:
>> For me, I think we should all work on getting used to
>> the idea that some Java objects *should not* be
>> synchronizable.  Well, that's already true, but let's
>> give our JVM permission to diagnose that particular
>> "should not" with an IllegalMonitorStateException
>> or something like that.  Bad?  Yes, but the least-bad,
>> where value types are concerned.
> 
> Is there a way to ease the pain? Probably you've considered this, but what if...
> 
> * Add a new interface NativeSynchronizable with wait/notify methods from Object
> * Code compiled using JDK 13 or later only allows
> synchronization/wait/notify on objects implementing
> NativeSynchronizable
> * But all class files compiled on JDK 12 or earlier are implicitly
> made to implement NativeSynchronizable (ie. interface injected at
> class load time based on the ClassFile version number)
> * All this can happen before and separate to value types
> 
> Would this not avoid the problems with older codebases?
> 
> Stephen