Wanted to get this logged but still working with customer and engineering to
determine if this is a bug in the customers app or a jdk 1.3 issue.



I wonder if you could help us with a rather serious problem we're seeing
> with the Standard Edition JDK 1.3 release? It appears that the contract
> between the Java VM and the ClassLoader has changed in a subtle but
> important way in JDK 1.3 compared to previous releases: in JDK 1.3 when
> the VM needs to load a class (e.g. to resolve a dynamically-linked
>reference),
> the VM calls a new private method on java.lang.ClassLoader called
> "loadClassInternal". This private method is synchronized on the class
> loader object, and that's what causes the problem.
>
> In prior releases, the VM simply called the loadClass(String) method on
> the class loader, which was NOT synchronized; this gave the class loader
> the opportunity to manage its own synchronization by appropriately
> overloading the loadClass(String) or loadClass(String, boolean) methods.
> Now, however, the class loader has no control over synchronization --
>because
> loadClassInternal is private and synchronized, the class loader is
> always called with the lock on the class loader object held.
>
> SilverStream uses a rather complicated class loading scheme to try to
> permit on-the-fly replacement of classes in a running app server; this
> involves using multiple class loaders including one which implements
> class path semantics (e.g. first look in Jar file A, then in Jar file
> B, etc.) This means that we often need to call more than one class
> loader in the course of loading a class, and that sometimes a call
> to loadClass() on class loader A actually results in the class being
> loaded (and defined) by class loader B. This no longer works reliably
> in JDK 1.3, because of deadlocks introduced by the new synchronized
> loadClassInternal method -- if the VM calls class loader A's
> loadClassInternal method, class loader A is now locked; A then must
> call a synchronized method in B. Other threads can perform these
> operations in the opposite order, resulting in a deadlock.
>
> We think that the change to use the synchronized loadClassInternal()
> method was an incompatible semantic change to class loading. We'd
> like to request that either:
> 1) The change be backed out; or
> 2) The loadClassInternal() method be made protected, so we can
> overload it in our class loaders to avoid the deadlock.
>
> Can you please contact the appropriate engineers in the JDK group
> to find out why this change was made and what the prospects for a
> fix to our problem are? Needless to say, this is pretty high-priority
> for us -- customers have already reported this deadlock when using
> the SilverStream application server with JDK 1.3, and we have no
> workaround for them at present.
>