It could be that they have custom classloader which isn't parallel
capable. So, this will still occur w/ jdk7 if this is the case.
We'll need to get some more information on the setup to reproduce the
issue. Given the time constraint, I'll file a bug to keep track of this
test case creation, but this will likely not be done for jdk7.
Thanks for all the comments/feedbacks,
Valerie
On 02/26/11 01:40 AM, Alan Bateman wrote:
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
