Valerie (Yu-Ching) Peng wrote:
David,
Thanks for the comments. I've updated the webrev accordingly at:
http://cr.openjdk.java.net/~valeriep/7001933/webrev.01/
In the case of a race condition, we'll just return the earlier defined
package object, i.e. pkg2 in your code sample.
Or, we could also get rid of this code block altogether, then there
shouldn't be a race condition. However, this means that we'll call
into the parent loader for the packages that they defined which
implies some performance cost.
I think the updated changes are okay/harmless but it's not completely
clear to me that the specific deadlock that this bug is about can
actually happen in jdk7 (because AppClassLoader is parallel capable).
It would be great to put in time to develop a test to demonstrate the
original issue, even if can't be an automated regression test (I've no
doubt that it would need to run many iterations to duplicate).
I also think we should submit a bug to re-examine how java.net.URL
behaves when java.protocol.handler.pkgs is set. Minimally I think it
needs to be clearer on the initiating loaders used when attempting to
load the protocol handler. In addition it's not clear to me that it
should fallback to the system class loader for the "file" protocol
handler as that is required early in the startup to define the system
package.
-Alan
