> Eduardo Pelegri-Llopart writes:
 > > As far as I can see, the existing code for UIDefaults.getUIClass()
 > > assumes that the classloader where UIDefaults is runnig is the same
 > > where the UIClass is [e.g. it does a plain Class.forName()].
 > >
 > > I'm running a BeanBox, on which I am loading javahelp.jar. When I
 > > try to instantiate a JHelpViewer component, UIDefaults cannot find
 > > my componentUI.
 > >
 > > At first sight, it would seem that UIManager.getUI(target) should
 > > find what is the classloader for target's class and try to locate
 > > the UI relative to it. But maybe you have something else in mind.

Hans Muller writes:
 > You're right and that is a significant bug. Unfortunately I don't think
 > just using the class loader of the target will work because that assumes
 > that the component, e.g. JSlider, will be loaded by the same class
 > loader as the look and feel. That would work for JavaHelp but not
 > for someone who was providing a new L&F for the built-in Swing classes.
 > I think this needs more thought. If you have any ideas let me know.

On the longer-term issue, I think that one "natural" way to do it is
to build on the default ComponentUI table. THat table is supposed to
map between a Componennt UID and the name of a class. Maybe it should map
to the name of a class + a classloader instace. Or to a "lazy value"
for a class object [I know Swing has the notion of a lazy value but I
don't know if it is powerful enough to use it this way].

Once a mechanism like that exists, a provider for a JComponent can use
the existing propertyChange event on "lookAndFeel" to register the proper
class to use.

- eduardo