Hi Peter, thanks for your feedback! I'm responding to both your messages in one.
> Am 09.08.2016 um 05:05 schrieb Peter Levart <peter.lev...@gmail.com > <mailto:peter.lev...@gmail.com>>: > 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 all of this, I think it is important to not let the idea creep in that IMs are members of some class. This is not to be the case. With that out of the way ;-) let me stress that this is a very good question, and there have in fact been discussions about this. The notion of "host" has been floating around, and it currently seems that the lookupClass - to which you refer as the "caller" - is a meaningful candidate for this. Does this answer your question? > On 08/09/2016 02:05 PM, Peter Levart wrote: >> 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. > > A can see now that defining an isolated method in the context of a lookup > class can only be allowed when the Lookup instance contains ALL_MODES in the > mode bits as such method would have access to any members that a normal > method defined in the lookup class has. Not sure. I think this suggestion implies something like class membership, when in fact the IM should have the access rights defined by the Lookup, without belonging to the lookupClass. I may be misunderstanding your point. > 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? Most aspects of this JEP draft, including the name, are open for discussion. :-) I would not want to call an IM "anonymous" because it should be given a name. If it is supposed to appear in a stack trace, that would be most helpful. The class to be displayed in this case can be the "host", but it should be displayed differently than usual to avoid the notion of class membership. Best, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java 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 <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
