Remove sun.misc.Unsafe.defineAnonymousClass

[Remi Forax]

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>
> Envoyé: Jeudi 23 Février 2017 02:22:27
> Objet: Remove sun.misc.Unsafe.defineAnonymousClass

> Hi,

Hi Paul,
my first reaction was 'over my dead body',
(you have sent this email to jigsaw-dev that i hope, it's just a mistake)

> 
> I think we should remove the method sun.misc.Unsafe.defineAnonymousClass.

so yes for 10 when public replacement APIs will be introduced, but no for 9.

> 
> This is one leaked through in the move to the unsupported module. I believe
> under the remit of unsupported module we can still do this.

It does not leaked, we discuss about removing it for 9 during the last JVM Summit,
and the consensus (i believe) was to add several public methods to cover all the 'features' of defineAnonymousClass in 10 before removing it.   

> 
> There are no usages on grepcode.com <http://grepcode.com/>, and we really don’t
> want anyone to start depending on this, especially for constant pool patching,
> where such a public API might require some careful thought, compared to the
> anon class support itself which is somewhat simpler.

disentangling the different 'features' of defineAnonymousClass also requires some thought, defineNestmate [1] is one step in the right direction (even if it still mix the fact that the class is not loaded by a classloader and the NestMate access), but by example for my proxy library [2], i still also need to be able to do the constant pool patching because i want to inject method handles that are not direct (i.e. live objects from the VM POV).

> 
> If developers really want constant pool patching they can crack open the
> jdk.internal.misc package and then they really know this is not supported.

I see this has being more evil that using sun.misc.Unsafe.
Nobody should use a non exported package like jdk.internal.misc. It's fine if you are in the middle of the migration process to 9 but jdk.internal.misc is a package introduced in 9, so nobody outside of the modules listed in the module-info should ever using it. 

> 
> For the anon class support we are considering retconning to nest mates and with
> a public method on MethodHandles.lookup.
> 
> Paul.

Rémi

[1] https://bugs.openjdk.java.net/browse/JDK-8171335
[2] https://github.com/forax/proxy2