RFR(S) 8139164: JVM should throw ClassFormatError for non-void methods named <clinit>

[Lois Foltan]

On 10/26/2015 11:41 AM, harold seigel wrote:
> Hi Lois,
>
> Thanks for the review.
>
> Methods that start with "<" but are not named "<clinit>" or "<init>" 
> are not legal method names and are detected quite early in class file 
> parsing by function ClassFileParser::verify_legal_method_name().  That 
> allows the subsequent parsing code to know that any method name 
> starting with "<" must be either a class initializer or object 
> initializer.
>
> Testing for methods whose names start with "<" but are not "<clinit>" 
> or "<init>" is a distinct issue from this bug and would require its 
> own bug, if need be.

Okay, thanks for pointing that out.  Looks good.
Lois

>
> Thanks, Harold
>
> On 10/26/2015 9:15 AM, Lois Foltan wrote:
>> Hi Harold,
>>
>> I think this looks good.  I don't see in any of the tests a test for 
>> a bogus internal method named something other than <clinit> or 
>> <init>.  Can you locate one if it exists or add one since your change 
>> is now checking all methods that start with "<", not just ones that 
>> are equal to vmSymbols::object_initializer_name().  Would this case 
>> pass for class files <= 51?
>>
>> Thanks,
>> Lois
>>
>> On 10/26/2015 8:31 AM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this small change to fix bug 8139164.
>>>
>>> Recent proposed JVM-9 Spec changes (JDK-8130682 
>>> <https://bugs.openjdk.java.net/browse/JDK-8130682>) require throwing 
>>> ClassFormatError exceptions for class file versions >= 51 for 
>>> methods named <clinit> that have one or more arguments or are not 
>>> static.  This fix implements that change.
>>>
>>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8139164/
>>>
>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8139164
>>>
>>> The fix was tested with JCK Lang, VM, and API java_lang tests, the 
>>> UTE quick and split verifier tests, and the hotspot, JDK vm, 
>>> java/io, java/lang, and java/util JTreg tests, and the tests 
>>> included in this RFR.
>>>
>>> Thanks, Harold
>>
>