felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Fixed bug in class loading
Date Tue, 11 Apr 2006 18:10:23 GMT
On Tue, 2006-04-11 at 02:42 -0400, Richard S. Hall wrote:
> John E. Conlon wrote:
> > On Mon, 2006-04-10 at 06:21 -0400, Richard S. Hall wrote:
> >   
> >> Or are you referring to a situation where you are running 
> >> into the bug I mentioned where your bundle does not directly use these 
> >> classes but you are still getting a class loading error?
> >>     
> >
> > Depends what you mean by directly. 
> >
> > My issue has to do with only some com.sun.* packages.  Specifically
> > swing plf packages. I misspoke on the previous email although I
> > mentioned sun.* classes I am not doing anything with them and did not
> > have to import these into my bundles. 
> >
> > In the case of these swing plf classes I don't import these classes and
> > use them directly but I do use strings to send them to a public
> > (factory) class for loading. 
> >
> > Here is how I am using the Swing plugable look and feel classes to give
> > the user of the GUI an option to load alternatives look and feels:
> >
> >
> > // Possible Look & Feels
> > 	private static final String mac =
> > "com.sun.java.swing.plaf.mac.MacLookAndFeel";
> >
> > 	private static final String metal =
> > "javax.swing.plaf.metal.MetalLookAndFeel";
> >
> > 	private static final String motif =
> > "com.sun.java.swing.plaf.motif.MotifLookAndFeel";
> >
> > 	private static final String windows =
> > "com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
> >
> > 	private static final String gtk =
> > "com.sun.java.swing.plaf.gtk.GTKLookAndFeel";
> >
> > // This eventual leads to a change an action that changes
> > // the look and feel with the following:
> >
> > String currentLookAndFeel=metal;
> > javax.swing.UIManager.setLookAndFeel(currentLookAndFeel);
> >   
> 
> Well, from my point of view, it definitely looks as if there is a 
> dependency, but I understand your dilemma since this is the way Sun 
> tells us to do things.
> 
> However, looking at this code, I would think that it wouldn't cause a 
> problem, because my "check" for implicit parent delegation in this case 
> should find javax.swing.UIManager on the class context stack and it 
> would know that this class was not loaded from a bundle, thus it would 
> delegate the class load request to the parent class loader. I would 
> really be interested in seeing a sample bundle of this if you could send 
> me something.

Yes you are correct the portion of the code above didn't cause the
problem but ...

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.

thanks for the patience,

John


Mime
View raw message