RFR: 8220607 Draft JEP: Hidden Classes

David Holmes david.holmes at oracle.com
Fri Dec 6 02:23:55 UTC 2019


On 6/12/2019 12:05 pm, Mandy Chung wrote:
> On 12/5/19 3:29 PM, Paul Sandoz wrote:
>> Very nicely written and extremely informative.
>>
> 
> Thanks.  Kudos to Alex B. for his feedback and improved writing.
>>
>> Since Nashorn was deprecated in 11 
>> (https://openjdk.java.net/jeps/335) is it worth updating it?
>>
>>
> 
> It was a good exercise to identify any migration challenge.  It turns 
> out it's straight-forward.
> 
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java.sdiff.html 
> 
> 
> Like the dynamic proxy, nashorn generates classes in a dynamic module 
> for strong encapsulation.   Allowing a hidden class to be injected in an 
> empty package is something we should look into in the future.
> 
>>
>>>> At run time, any attempt to resolve a hidden class by name, it may 
>> result in a LinkageError which is no difference from resolving a 
>> symbolic reference to an ordinary class that cannot be found.
>>>> ->
>>>> At run time, any attempt to resolve a hidden class by name may result 
>> in a LinkageError, which is no differer from resolving a symbolic 
>> reference to an ordinary class that cannot be found.
>> "
>>
>> “May” or “will” ?
>>
> 
> Should be "will".  I have to remind myself why I wrote "may" at that 
> time (it has been quite some time ago).

It's unclear to me from that text whether this is referring to the 
augmented name of the hidden class ie. com.example.Foo/1234, or the name 
that may be present in the byte array. If the former then LE will be 
thrown. If the latter then LE may be thrown as you may have a different 
classfile using the same name.

BTW typo: "no difference" -> "no different"

Cheers,
David

> :
> 
>>
>>>> Accordingly, hidden classes will not have the ability to control their 
>> optimization, even when defined by JDK code. (This is not thought to 
>> present any risk to the migration of JDK code from defining 
>> VM-anonymous classes to defining hidden classes.)
>>>>
>> (You probably know this…) FWIW it's not the case for classes defined 
>> for lambda forms which do make use of @DontInline and @ForceInline. 
>>  Although such classes are generated with patching, so when public 
>> support for patching is added this assumption may need to be revised 
>> if we want to replace the Unsafe usages.
> 
> Lambda forms are trusted classes defined by the bootstrap class loader 
> and so they get access to these VM internal annotations.
> 
> It's replaced with a package-private 
> Lookup::defineHiddenClassWithClassData for now.
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.12-03-2019/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java.udiff.html 
> 
> 
>>
>> What about final fields being implicitly stable fields for classes in 
>> java.lang.invoke?
>>
> 
> AFAICS, hidden class doesn't affect this at all as it's determined by 
> java.lang.invoke package, right?
> 
>> I would presume a hidden class might inherit such policies from its 
>> lookup class.
>>
> 
> I will double check.
> 
> Mandy
> 
> 


More information about the valhalla-dev mailing list