MultiLookAndFeel: many UI-delegates break if auxiliary LF is added

FULL PRODUCT VERSION :
all versions (up-to and including the mustang snapshot build 44)

ADDITIONAL OS VERSION INFORMATION :
irrelevant

EXTRA RELEVANT SYSTEM CONFIGURATION :
irrelevant

A DESCRIPTION OF THE PROBLEM :
The problem is any code in the ui-delegates that tries to get hold of a special type of LookAndFeel and ui-delegate class:

if (mycomp.getUI() instanceof SomeUI) {
    dosomething();
}

myUI = mycomp.getUI();
if (myUI instanceof SomeUI) {
   dosomething();
}

myUI = BasicLF.getUIOfType(mycomp.getUI(), SomeUI.class);
if (myUI != null) {
  dosomething();
}

(similar for checking the type of LookandFeel)

In all these cases the dosomething() is not executed if an auxiliary LF is added: then the getUI() returns MultiLookAndFeel and the instanceof check is false.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

nothing to reproduce - some behaviour silently isn't executed. Before fixing #4842445 an error was thrown. The fix solved the underlying reason - the returned ui is MultiLookAndFeel - only incompletely.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

no code - it's a code quality error! I rate the severity high because any application is potentially unstable as soon as an aux LF is set. This instability may express itself at unexpected places ("loading audiomap doesn't work") , the real reason difficult to locate and such requiring long and difficult debugging sessions. There's nothing an application programmer can do to solve - short of not adding aux LF.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :

no workaround, this is solvable in core swing only. All ui-delegates need to be aware of the MultiLF:

ui = mycomp.getUI
if (uiinstanceof MultiXXUI)
   ui= ((MultiXXUI) myui).getUIs()[0]
myui = BasicLF.getUIOfType(ui, someui.class);
if (myui != null)
  dosomething();

similar for LookAndFeel types.

In the long run this should be moved as a public service into LookAndFeel: this requires to add some means to recognize a MultiXXUIs - f.i. an interface with the method getUIs and the same contract as the multiXXUIs getUIs(). It's important to guarantee that the first entry has the "real" UI.

Have fun when cleaning up <g>

Jeanette