RFR: JDK-8215407: Javadoc throws StringIndexOutOfBoundsException: String index out of range: -2

[Jan Lahoda]

On 16.3.2019 01:10, Jonathan Gibbons wrote:
> OK, I see the additional checks in simpleBinaryName, which is the sort
> of check I was expecting.
>
> I'm a bit surprised you didn't put the check inside simpleBinaryName,
> but that would trigger a subsequent question as to why we have

I started with the check inside the simpleBinaryName method, but then 
moved it outside, as the check seemed like a "general" check, not 
something related to the simple name as such. I don't have a very strong 
opinion on this, I can move the check inside simpleBinaryName if preferred.

Thanks,
     Jan

>
> 1478 throw badEnclosingMethod(self);
>
> and ClassReader.simpleBinaryName:1507
>
>      throw badClassFile("bad.enclosing.method", self);
>
> I'm OK with either webrev as is or with the check moved into
> simpleBinaryName,
>
> -- Jon
>
> On 03/06/2019 02:31 AM, Jan Lahoda wrote:
>> Hi Jon,
>>
>> On 5.3.2019 21:20, Jonathan Gibbons wrote:
>>> Jan,
>>>
>>> Is checking for a prefix good enough?   It seems like that would be
>>> necessary but not sufficient.
>>
>> What specific additional checks do you foresee? The
>> ClassReader.simpleBinaryName method does some additional checks, like
>> that the class suffix is non-empty and starts with '$'.
>>
>> Thanks,
>>     Jan
>>
>>>
>>> -- Jon
>>>
>>> On 3/5/19 9:00 AM, Jan Lahoda wrote:
>>>> On 5.3.2019 17:33, Joe Darcy wrote:
>>>>> Hi Jan,
>>>>>
>>>>> Do you think this issue merits a CSR for the behavioral change?
>>>>
>>>> Good question! It is true that javac may now refuse to load classfiles
>>>> that didn't lead to the exception before, so I guess a CSR may be in
>>>> order. I've started with it here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8220167
>>>>
>>>> Feedback on the CSR is very welcome as well!
>>>>
>>>> Thanks,
>>>>     Jan
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 3/5/2019 7:55 AM, Jan Lahoda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Seems that some classfiles have a weird EnclosingMethod attribute -
>>>>>> for (local/anonymous) class A, the EnclosingMethod attribute states
>>>>>> the enclosing class is C, but the name of C is not a prefix of the
>>>>>> name of A. This appears to be contradictory to JLS 13.1., so the
>>>>>> proposal is to reject such classfiles.
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~jlahoda/8215407/webrev.00/
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8215407
>>>>>>
>>>>>> How does this look?
>>>>>>
>>>>>> Thanks,
>>>>>>     Jan
>