This problem came to light when writing a Swing applet, which includes
a custom Look and Feel, downloaded from the applet's codebase.

This could be made to work with appletviewer and HotJava but not
with the Java Plugin.
With Plugin the applet would get errors like:-

"ClassNotFoundException: CustomLookAndFeel"
when making the call
UIManager.setLookAndFeel("CustomLookAndFeel")

Or if the code is changed to directly instantiate an instance of
the PLAF,

  UIManager.setLookAndFeel(claf = new CustomLookAndFeel());

then the Look and Feel loads correctly, but when you attempt to
instantiate a Swing component , you get:-
 
  UIDefaults.getUI() failed: no ComponentUI class for:
  com.sun.java.swing.JList[,0,0,0x0,invalid]
  java.lang.Error
  at java.lang.Throwable.<init>(Compiled Code)
  at java.lang.Error.<init>(Compiled Code)
  at com.sun.java.swing.UIDefaults.getUIError(UIDefaults.java:296)
  at com.sun.java.swing.UIDefaults.getUI(Compiled Code)
  at com.sun.java.swing.UIManager.getUI(Compiled Code)
  at com.sun.java.swing.JList.updateUI(JList.java:314)
  at com.sun.java.swing.JList.<init>(JList.java:237)
  at com.sun.java.swing.JList.<init>(JList.java:248)
  at CustomLookAndFeel.commonStartup(CustomLookAndFeel.java:74)
  at CustomLookAndFee.init(CustomLookAndFeel.java:21)
  at sun.applet.AppletPanel.run(Compiled Code)
  at java.lang.Thread.run(Compiled Code)

The key difference is that the Java Plugin includes the swingall.jar,
and so Swing is loaded by the native system classloader, whereas in the
case of the appletviewer, the applet tag includes the swing.jar in the
ARCHIVE tag, so it was downloaded and hence had the same classloader
as the applet and the custom look and feel.

Swing uses class.forName() to locate the UI classes and the Look and Feel
class.
class.forName() will use the class loader of the invoking class.
Since that is a Swing class, loaded from local disk, getClass.getClassLoader()
returns null.
This bug is the same problem as reported in bug 4120021.
That bug has been fixed for the case where a component is downloaded
The fix there in getUI() gets the classloader of the target component.
  ClassLoader uiClassLoader = target.getClass().getClassLoader();
and uses that to locate the class.

In this case what is needed is more like

ClassLoader uiClassLoader = (UIManager.getLookAndFeel()).getClass().getClassLoader();

That's still not quite right since it doesn't help in
the setLookAndFeel method, or solve the downloaded component case.

=======================================================================


phil.race@eng 1998-08-03

Under JDK 1.2 Beta4, application classes are loaded by a classloader
instance, so this bug effectively prevents the whole custom L&F architecture
of Swing from functioning evenm for applications.

See http://java.sun.com/products/jdk/1.2/compatibility.html, Bullet #7
for more info on this.

The following things break:
    - UIManager.setLookAndFeel("myCustomLAFName")
    - attempts to use an auxiliary L&F
    - attempts to install a single custom UI delegate
=======================================================================