[nestmates] Name of a hidden class and stack trace

[Mandy Chung]

One thought I have is to tag along a bit in the modifiers and
of course getModifiers will have to mask with the legal bits.

Mandy

On 8/29/19 1:28 PM, Remi Forax wrote:
> Yes,
> resing the same scheme is fine.
>
> BTW, is there a better way to test hidden classes ?
>
> Rémi
>
> ----- 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.
>>
>> Mandy
>>
>> 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
>>>> foo/Foo.class
>>>> 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.
>>>>
>>>> Thought?
>>>>
>>>> Mandy