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
MethodHandles.Lookup.revealDirect().//"/
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. :-)
https://bugs.openjdk.java.net/browse/JDK-8158765
Thanks,
Michael
--
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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
