On Thu, 2007-05-24 at 11:00 +0100, Glyn Normington wrote: > A better approach would be for the Java 7 platform to provide first > class support for JSR 291. This boils down to standardising the > experimental class loader deadlock fix ([1])
Fixing the deadlock just moves the problem. You'll still get ClassCircularityErrors when competing threads try to load classes using locks other than the classloader synchronization or they don't synchronize on the loadClass() or they release the lock during the classloading request to let others have a go (again to avoid the deadlock). This is because of the way the dictionary class determines whether a circular load is occuring. Although I haven't tried it with OpenJDK so maybe the dictionary class contains some other fixes to workaround the problem? The simple form of the problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4699981 has been fixed in recent JDKs, but spurious CCEs still exist in other cases. e.g. the testAbstractFactoryConcurrent() here: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontainer/trunk/classloader/src/tests/org/jboss/test/classloader/delegate/test/DelegateUnitTestCase.java?revision=62792&view=markup will show CCEs in the log if you enable TRACE logging. 1445 TRACE [ClassLoaderManager] Run failed with exception java.lang.ClassCircularityError: org/jboss/test/classloader/delegate/support/b/TestFactoryImplementation at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx
