RFR: 8220607 Draft JEP: Hidden Classes
mandy.chung at oracle.com
Fri Dec 6 02:05:23 UTC 2019
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.
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.
> What about final fields being implicitly stable fields for classes in
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.
More information about the valhalla-dev