----- Mail original ----- > De: "Paul Sandoz" <[email protected]> > À: "jigsaw-dev" <[email protected]> > Cc: "Brian Goetz" <[email protected]> > 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
