[nestmates] Name of a hidden class and stack trace
forax at univ-mlv.fr
Thu Aug 29 20:28:57 UTC 2019
resing the same scheme is fine.
BTW, is there a better way to test hidden classes ?
----- Mail original -----
> De: "mandy chung" <mandy.chung at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Jeudi 29 Août 2019 20:44:47
> Objet: Re: [nestmates] Name of a hidden class and stack trace
> Yes, I forgot to mention that is another reason to keep '/' rather than
> another scheme.
> On 8/29/19 11:42 AM, Brian Goetz wrote:
>> This trick has worked well for us with anon classes, and there’s already plenty
>> of code out there that does `name.contains(‘/‘)` to defend against it, so I see
>> no reason to break from this convention.
>>> On Aug 29, 2019, at 2:34 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> I'm writing a JEP proposal of hidden/nestmate/weak classes prototyped in the
>>> nestmates branch (JDK-8171335). Attached describes about hidden classes
>>> (thanks to Alex Buckley for the help) and description about nestmates/weak will
>>> come next.
>>> A hidden class cannot be named by other class. Ideally a hidden class should
>>> be nameless. For troubleshooting and stack trace, a hidden class needs a
>>> name. So the proposal has been:
>>> Class::getName returns a name for a hidden class and the name is unique in the
>>> runtime package namespace. That is, there is no two Class objects with the
>>> same name in the same runtime package.
>>> Below shows the stack trace where a hidden class throws an exception.
>>> $ java -XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames DefineClass
>>> java.lang.Error: error
>>> at foo.Foo_/0x0000000800b79258.run(Foo.java:9)
>>> at DefineClass.main(DefineClass.java:18)
>>> The current impl includes `/` in the hidden class's name to disjoint from the
>>> ordinary class names
>>> (same trick as VM anonymous class).
>>> Another class calls Class::forName with the hidden class's name which would fail
>>> since that's not a valid binary name. If someone attempts to spin a class
>>> referencing this hidden class's name with replace('.', '/'), it may attempt to
>>> load a class named 'foo/Foo_/0x0000000800b79258' and may succeed if such a
>>> class file exists and can be located by class loader. This is no difference
>>> than today as one can spin a class file to any class names.
>>> Class::getName may return an invalid binary name if it's a hidden class. It
>>> will impact existing code that expects the returned name is a valid binary name
>>> or use the name to perform class lookup. I think the compatibility concern
>>> should not be high.
More information about the valhalla-dev