RFR (S) 8001108: an attempt to use "<init>" as a method name should elicit NoSuchMethodException

[Christian Thalinger]

On Sep 19, 2013, at 2:31 PM, John Rose <john.r.rose at oracle.com> wrote:

> 
> On Sep 18, 2013, at 5:05 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> src/share/classes/java/lang/invoke/MethodHandles.java:
>> 
>> +     * methods as if they were normal methods, but the JVM verifier rejects them.
>> 
>> I think you should say "JVM byte code verifier" here.
> 
> Done.  s/byte code/bytecode/.
> 
>> 
>> +         * <em>(Note:  JVM internal methods named {@code <init>} not visible to this API,
>> +         * even though the {@code invokespecial} instruction can refer to them
>> +         * in special circumstances.  Use {@link #findConstructor findConstructor}
>> 
>> Not exactly sure but should this read "are not visible"?
> 
> Yes.
> 
>> 
>>        MemberName resolveOrFail(byte refKind, Class<?> refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException {
>> +            type.getClass();  // NPE
>>            checkSymbolicClass(refc);  // do this before attempting to resolve
>> -            name.getClass(); type.getClass();  // NPE
>> +            checkMethodName(refKind, name);
>> 
>> Could you add a comment here saying that checkMethodName does an implicit null pointer check on name?  Maybe a comment for checkMethodName too.
> 
> Done.
> 
>> 
>> What was the problem with the null pointer exceptions?  Is it okay that we might throw another exception before null checking name?
> 
> Foo.  The reordering of those null checks seems to be a needless change that crept in.  I'm going to keep them the way they are.
> 
> See updated webrev:
>  http://cr.openjdk.java.net/~jrose/8001108/webrev.01/

Looks good.

> 
> — John
> 
>> On Sep 12, 2013, at 6:47 PM, John Rose <john.r.rose at oracle.com> wrote:
>> 
>>> Please review this change for a change to the JSR 292 implementation:
>>> 
>>> http://cr.openjdk.java.net/~jrose/8001108/webrev.00
>>> 
>>> Summary: add an explicit check for leading "<", upgrade the unit tests
>>> 
>>> The change is mostly to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
>>> 
>>> In the RI, there is an explicit error check.
>>> 
>>> Thanks,
>>> — John
>>> 
>>> P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
>>> Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev