java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

[Peter Levart]

Hi,

Are '.' and '/' the only characters on the table? The problems with 
those are that both are used as hierarchical name delimiters in one way 
or another and code exists that converts one to another. If there was a 
3rd character chosen such that:

- it would make the descriptor "invalid" for resolving
- otherwise not be unexpected in parsing logic

...then such composition would be ideal. I think that there could event 
be a place for such names in the specification: syntactically valid but 
unresolvable names.

The problem is that it is hard to find such a character isn't it? But 
let's try...

What about character '\' - backslash ? It seems very unlikely that this 
character would appear in the name of a class. In Java language it is 
not allowed, but even in other languages it is probably treated as some 
kind of delimiter and therefore unlikely to be part of the derived class 
name. Would it be too much to declare that it must not appear in the 
name of the class?

Even if it was not forbidden, it would be very unlikely to appear in 
practice. By analogy: Java anonymous classes are kind of "hidden", just 
on another level - in the language. They do use valid class names 
though, even valid in Java language, but there's no problem with that in 
practice. Why? Because the outer class typically controls the 
"namespace" where they appear in. With java modules, there is additional 
control that is imposed on the package namespace.

Regards, Peter


On 4/12/20 5:35 AM, Mandy Chung wrote:
>
>
> On 4/8/20 3:35 PM, John Rose wrote:
>> On Apr 8, 2020, at 3:31 PM, John Rose <john.r.rose at oracle.com 
>> <mailto:john.r.rose at oracle.com>> wrote:
>>>
>>> In both c and c’ there will probably be a cascading failure
>>> if the name foo/Bar/123Z or foo/Bar is resolved.  In c’ there
>>> is an additional cascading failure when the user that was
>>> parsing the signature goes back for more parameters and
>>> finds a slash (instead of LZBHCIJFD[).  The thing that tipped
>>> me over to c’ is that extra diagnostic: Even though it happens
>>> after the user picked up the bad descriptor, it happens closer
>>> to the place where the error has its root cause, which is that
>>> somebody is trying to parse an (intentionally) illegal descriptor.
>>
>> P.S. Having the slash+suffix *outside* the L; envelope basically
>> rubs any parser’s nose in the fact that there’s something illegal
>> here.  Putting it inside the envelope hides the error from the
>> parser—which may be a good thing sometimes!  But it means
>> that the odd name foo/Bar.123Z will float somewhere else
>> and may or may not be misinterpreted.  If it’s handed to
>> Class.forName you can bet that the dot will change its meaning.
>> On balance, I slightly prefer the fail-fast properties of c’.
>
> Thanks John.
>
> I have implemented to define the descriptor string for a hidden class 
> of this form:
>      "L" + N + ";" + "/" + <suffix>
>
> Please see [1] for the review thread.
>
> For your reference, the webrev is:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.06-delta/ 
>
>
> Specdiff:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff-inc/overview-summary.html 
>
>
> The spec of `Lookup::defineHiddenClass`, `Class::descriptorString` and
> `MethodType::descriptorString` are updated to return the descriptor of
> this form for a hidden class.   To support hidden class,
> `java.lang.invoke.TypeDescriptor` spec is revised such that a
> `TypeDescriptor` object can represent an entity that may not be
> described in nominal form.   The serviceability APIs that return a type
> descriptor are updated.  This webrev includes a couple other JVM TI and
> java.instrument spec clarification w.r.t. hidden classes.
>
> Mandy
> [1] 
> https://mail.openjdk.java.net/pipermail/valhalla-dev/2020-April/007121.html