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.
+ * <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"?
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.
What was the problem with the null pointer exceptions? Is it okay that we
might throw another exception before null checking name?
On Sep 12, 2013, at 6:47 PM, John Rose <john.r.r...@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-...@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
