RFR: 8220607 Draft JEP: Hidden Classes

[Mandy Chung]

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).

:

>
> “
> 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