Re: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
On 2013-09-08, at 10:39 PM, David Holmes david.hol...@oracle.com wrote: On 7/09/2013 1:28 AM, Alan Bateman wrote: On 06/09/2013 15:18, David Chase wrote: webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ Question #2, what's the best way to write a jtreg test suite that requires incompatible class files, that could not result from a single javac compilation? Can you coerce ASM into creating it? Alternatively it is something that you can create off-line and include in a class as a byte array (to load via your own URLClassLoader)? Multiple @compile tags in the main test? I did it with a hacked classloader instead, see the message with RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError (webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/ ) I figured it could not be small if it included multiple files in the test. David
Re: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
On 7/09/2013 1:28 AM, Alan Bateman wrote: On 06/09/2013 15:18, David Chase wrote: webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ Question #2, what's the best way to write a jtreg test suite that requires incompatible class files, that could not result from a single javac compilation? Can you coerce ASM into creating it? Alternatively it is something that you can create off-line and include in a class as a byte array (to load via your own URLClassLoader)? Multiple @compile tags in the main test? David - Question #3, the message(s) attached to the exception are not the same in all cases: a. IllegalAccessError's been caught java.lang.IllegalAccessError: member is private: MethodSupplier.m()void/invokeVirtual, from MethodInvoker b. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker c. IllegalAccessError's been caught java.lang.IllegalAccessError: d. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker The difference between a. and c. above (and these are the two that change under this fix, the code the execution definitely intersects at the fix) is: a = Class.forName(MethodInvoker).getMethod(invoke).invoke(null); c = MethodInvoker.invoke(); yet one has the message copied from the underlying IllegalAccessException (not IAError) and the other does not. Do you mean you want the messages to be consistent? (I don't think I quite get the question). -Alan
Re: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
On 06/09/2013 15:18, David Chase wrote: webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ bug: The bug report is not correct, but there is nonetheless a related underlying bug where IllegalAccessError fails to be thrown. Question #1, is this a corelibs bug? It was filed against compiler, but the fix is in the jdk classes, but it is MethodHandle code. component=core-libs, subcomonent=java.lang.invoke is probably what you are looking for. I think most of the discussion on method handles is on mlvm-dev although it pop up here periodically too. Question #2, what's the best way to write a jtreg test suite that requires incompatible class files, that could not result from a single javac compilation? Can you coerce ASM into creating it? Alternatively it is something that you can create off-line and include in a class as a byte array (to load via your own URLClassLoader)? Question #3, the message(s) attached to the exception are not the same in all cases: a. IllegalAccessError's been caught java.lang.IllegalAccessError: member is private: MethodSupplier.m()void/invokeVirtual, from MethodInvoker b. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker c. IllegalAccessError's been caught java.lang.IllegalAccessError: d. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker The difference between a. and c. above (and these are the two that change under this fix, the code the execution definitely intersects at the fix) is: a = Class.forName(MethodInvoker).getMethod(invoke).invoke(null); c = MethodInvoker.invoke(); yet one has the message copied from the underlying IllegalAccessException (not IAError) and the other does not. Do you mean you want the messages to be consistent? (I don't think I quite get the question). -Alan
Re: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
On 2013-09-06, at 11:28 AM, Alan Bateman alan.bate...@oracle.com wrote: On 06/09/2013 15:18, David Chase wrote: webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.00/ bug: The bug report is not correct, but there is nonetheless a related underlying bug where IllegalAccessError fails to be thrown. Question #1, is this a corelibs bug? It was filed against compiler, but the fix is in the jdk classes, but it is MethodHandle code. component=core-libs, subcomonent=java.lang.invoke is probably what you are looking for. I think most of the discussion on method handles is on mlvm-dev although it pop up here periodically too. Question #2, what's the best way to write a jtreg test suite that requires incompatible class files, that could not result from a single javac compilation? Can you coerce ASM into creating it? Alternatively it is something that you can create off-line and include in a class as a byte array (to load via your own URLClassLoader)? Question #3, the message(s) attached to the exception are not the same in all cases: a. IllegalAccessError's been caught java.lang.IllegalAccessError: member is private: MethodSupplier.m()void/invokeVirtual, from MethodInvoker b. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker c. IllegalAccessError's been caught java.lang.IllegalAccessError: d. IllegalAccessError's been caught java.lang.IllegalAccessError: tried to access method MethodSupplier.m()V from class MethodInvoker The difference between a. and c. above (and these are the two that change under this fix, the code the execution definitely intersects at the fix) is: a = Class.forName(MethodInvoker).getMethod(invoke).invoke(null); c = MethodInvoker.invoke(); yet one has the message copied from the underlying IllegalAccessException (not IAError) and the other does not. Do you mean you want the messages to be consistent? (I don't think I quite get the question). Since all four messages all refer to the same underlying fault, there is some reason to think that they should be consistent. However, the spec is not that detailed, nor am I that determined, and I think the one that is empty is being stripped through some other mechanism that I don't yet understand. I was hoping I would not need to reactivate all the classloader-hacking neurons, but it looks like that will be necessary. I had hope to avoid that complication; the simpler the test, the better. David
