Re: RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
On 2013-09-08, at 10:39 PM, David Holmes 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 2013-09-06, at 11:28 AM, Alan Bateman 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
RFR(S) / guidance, 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
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.
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?
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.
David
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
