java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
peter.levart at gmail.com
Sun Apr 12 08:28:06 UTC 2020
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
The problem is that it is hard to find such a character isn't it? But
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.
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  for the review thread.
> For your reference, the webrev is:
> 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.
More information about the valhalla-dev