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