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
