java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
peter.levart at gmail.com
Sun Apr 12 11:13:28 UTC 2020
On 4/9/20 12:35 AM, John Rose wrote:
> On Apr 8, 2020, at 3:31 PM, John Rose <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’.
The problem I see is that some "parsers" might only be concerned about
for example counting the number of parameters in the method type
descriptor. Suddenly the syntax for doing so has changed very much. With
'c' there is no such problem. L; has long been the "envelope" and now it
won't be any more.
I think that:
...are not valid (were some of them valid at some time in the past?).
So there's no problem of confusingly misinterpreting names of the form
"foo/Bar.suffix" or "foo.Bar/suffix" in the public APIs.
I think it would be less problematic to adopt 'c' than 'c`' ...
More information about the valhalla-dev