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

[John Rose]

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/

— 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