Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <443CF3A0.3040602@ungoverned.org>
Date: Wed, 12 Apr 2006 08:33:36 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 1.5 (X11/20060313)
MIME-Version: 1.0
To: felix-dev@incubator.apache.org
Subject: Re: Fixed bug in class loading
References: <443385C0.9070707@ungoverned.org>
  <1144362144.3702.22.camel@trout>  <443A319B.8070301@ungoverned.org>
  <1144721016.4055.277.camel@trout>  <443B4FEE.7040103@ungoverned.org>
 <1144779023.3784.26.camel@trout> <443CA2FD.9030808@ungoverned.org>
 <185136104.20060412101024@aQute.se> <443CC435.3010708@ungoverned.org>
 <33071412.20060412142823@aQute.se>
In-Reply-To: <33071412.20060412142823@aQute.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Kriens wrote:
> If you do not only diagnose the problem but also can show potential
> cures then I think being a strict is not a problem.
>   

Yep, that is what I am looking to do. We will see how well it can be 
diagnosed, but I think it is worth trying.

-> richard
> Kind regards,
>
>      Peter Kriens
>      
> RSH> Peter Kriens wrote:
>   
>>> RSH> My desire is not to cause people using Felix any undue pain. I certainly
>>> RSH> want Felix to work properly out of the box, but how will we ever learn
>>> RSH> about these issues and improve the situation if we never try?
>>> Maybe you can log any delegation to the bootclasspath as a warning?
>>>   
>>>       
>
> RSH> Yes, that is a possibility. However, the Swing LAF example that was 
> RSH> resolved without needing to import "com.sun.*" or "sun.*" is really 
> RSH> telling. By exposing these hidden dependencies in a more strict way, 
> RSH> then we can actually learn something from them. Making them too easy to
> RSH> ignore just creates more of the same issues.
>
> RSH> Still, I agree that we should try to make being more strict as painless
> RSH> as possible. Another possible approach is for us to try to improve 
> RSH> Felix' error diagnostics when a class loading error occurs. For example,
> RSH> we could:
>
> RSH>     * Check to see if there are exporters of the package, but no import
> RSH>       and suggest adding it to the Import-Package declaration.
> RSH>     * Check to see if the class is available from the system class
> RSH>       loader and suggest adding the package to the system bundle's packages.
> RSH>     * Check to see if the class is being loaded using
> RSH>       ClassLoader.loadClassInternal() by examing the stack trace and
> RSH>       suggest to add the package to the boot delegation property.
>
> RSH> Perhaps there are other possible diagnostics that could help developers
> RSH> when they encounter a class loading error.
>
> ->> richard
>
>   
>>> Kind regards,
>>>
>>>      Peter Kriens
>>>
>>> RSH> 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.
>>>>>       
>>>>>           
>>> RSH> Interesting. Thanks for looking into this in detail.
>>>
>>> RSH> However, did you check out the latest version of Felix since I did add
>>> RSH> "com.sun.*" and "sun.*" to the boot delegation property.
>>>
>>> RSH> If this is accurate, then it basically demonstrates my thinking exactly.
>>> RSH> We either can by default try to be a little more strict and look into 
>>> RSH> problems and try to figure them out in a proper modular fashion or do we
>>> RSH> just forget about it and allow more and more and more legacy to be built
>>> RSH> with the same modularity problems. I am in the camp of the former.
>>>
>>> RSH> My desire is not to cause people using Felix any undue pain. I certainly
>>> RSH> want Felix to work properly out of the box, but how will we ever learn
>>> RSH> about these issues and improve the situation if we never try?
>>>
>>> ->> richard
>>>
>>>
>>>   
>>>       
>
>