On Sep 18, 2013, at 5:05 PM, Christian Thalinger
<[email protected]> 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 <[email protected]> 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
>> [email protected]
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
> _______________________________________________
> mlvm-dev mailing list
> [email protected]
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
