Hi Michael,

In the JEP's description you write:

   /"The loadCode method creates a method from the passed bytecode
   instructions and constants and returns a MethodHandle that can be
   used to call the method. The implementation of loadCode will take
   care of verification of the code to load.//"/

That's clear.


   /"This method is isolated from any class and behaves largely like a
   static method. The method handle resulting from a loadCode
   invocation is of the REF_static kind. It cannot be cracked via

So there will be no class hosting this method? Not even the "caller" class of the Lookup instance that loadCode was invoked upon? What will be reported by Reflection.getCallerClass() invoked in a @CallerSensitive method invoked from the isolated method? Perhaps the following is a hint...


   /"The context for a method defined in this way is determined by the
   Lookup instance receiving the loadCode call. In case the lookup
   privileges are not sufficient, an exception will be thrown.//"


The "context" meaning the caller context, including the caller class that appears in the stack trace of a call originating from an isolated method and is important for security decisions?

In which case would lookup privileges be insufficient to define an isolated method? I would expect the privileges of the code in the isolated method to be checked when such method is executed and not when defining such method - lazily, like for normal methods. In which case it is important which "caller" class the privileges are check against. This would most naturally be the "caller" class of the Lookup instance used to define the method. In all respects the code of such isolated method would appear to be defined in the lookup class except it would not be denotable symbolically - only through a MethodHandle. Analogous to VM-anonymous classes. So why not call such methods "anonymous methods" instead of isolated methods?

Regards, Peter

On 08/05/2016 06:33 PM, Michael Haupt wrote:
Dear all,

during the Indy workshop at JVMLS, a JEP draft supposed to enable the loading of methods in isolation was mentioned and discussed. This JEP draft is now public, and I'd like to invite The Interested Parties (you know who you are) to tear it apart in a constructive manner. :-)





Oracle <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
OracleJava Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

mlvm-dev mailing list

mlvm-dev mailing list

Reply via email to