John E. Conlon wrote:
the problem lay in another part of the class where I build the menu
items to allow the user to change the configuration of the LAF. For that
I needed to determine if my string classnames were accessible.
Here is the problematic way:
static boolean isAvailableLookAndFeel(String laf) {
try {
Class lnfClass = Class.forName(laf);
LookAndFeel newLAF = (LookAndFeel) (lnfClass.newInstance());
return newLAF.isSupportedLookAndFeel();
} catch (Exception e) {
return false;
}
}
The right way to do this is to use the
javax.swing.UIManager.getInstalledLookAndFeels() method
which returns an array of LookAndFeelInfo objects. An LookAndFeelInfo
object can then be used for building the menu items.
After refactoring the class I was able to remove the
com.sun.java.swing.plaf.gtk;
com.sun.java.swing.plaf.motif;
package imports from the bundle and the from the
org.osgi.framework.system.packages property.
The bundle then loaded without error.
Interesting. Thanks for looking into this in detail.
However, did you check out the latest version of Felix since I did add
"com.sun.*" and "sun.*" to the boot delegation property.
If this is accurate, then it basically demonstrates my thinking exactly.
We either can by default try to be a little more strict and look into
problems and try to figure them out in a proper modular fashion or do we
just forget about it and allow more and more and more legacy to be built
with the same modularity problems. I am in the camp of the former.
My desire is not to cause people using Felix any undue pain. I certainly
want Felix to work properly out of the box, but how will we ever learn
about these issues and improve the situation if we never try?
-> richard