felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Walker <r...@ascert.com>
Subject Re: Fixed bug in class loading
Date Thu, 13 Apr 2006 08:52:23 GMT

Very interesting conclusion.

I have to confess when Oscar2 was first in the works we were completely 
against strict class loading - in fact our classloading was looser than 
most as we'd hacked Oscar1 to allow .* wildcard imports and exports. We 
new we couldn't live like this for long though and the benefits of being 
on standard Oscar2 base code outweighed the small advantage - so we 
wrote mangen to take away the import/export pain. It's far from perfect, 
but since it became part of our production build we haven't had a single 
import/export related bug or problem - and we had them every week 
before. We also noticed mangen started "finding" package dependencies we 
had never known existed and which potentially could have been the source 
of future bugs  - L&F's were a classic example.

And for anyone working with XML - strict classloading is definitely your 
friend. Sadly Sun have done some horrible things with various XML APIs 
and classlibs of late - at some stage our packaged xalan JARs ended up 
not being used because a later JDK included it's own which broke 
everything else. Strict classloading gives you ways to (a) spot this; 
and (b) manage it.

So my vote would be: strict classloading + tools to make it easier to 
work with.

-- Rob

Richard S. Hall wrote:

> Another, perhaps encouraging, turn in this saga.
> The reason why we got into this strict class loading discussion (and 
> subsequent Felix class loading bug fix) at all, was because I noticed 
> these issues when moving the Shell GUI bundles to Felix.
> This caused me to fix strict class loading that was accidentally 
> broken, but with it enabled I was discouraged because the Shell GUI 
> Plugin bundle needed to import javax.swing.text because I was getting 
> a class load error for javax.swing.text.JTextComponent, which is the 
> superclass of javax.swing.JTextArea. I was discouraged because the 
> code did not use JTextComponent, only JTextArea. Since I could not see 
> any usage of JTextComponent in the code I assumed that this was 
> related to similar situations we have seen before that either 1) the 
> Swing library was making faulty assumptions or 2) the VM was doing 
> something strange. As it turns out in this case, neither was true.
> Peter Kriens spent some time yesterday investigating the bundles 
> causing the problem and discovered that there was an implicit 
> dependency in the Shell GUI Plugin to javax.swing.text.JTextComponent. 
> Although the bundle was using methods via on JTextArea, some of those 
> methods were inherited from JTextComponent, such as setText(). In such 
> situations the reference to this method in the byte code is actually 
> on the superclass and not on the subtype.
> Thus, I originally thought that I was being forced to add an 
> unnecessary import to my bundle for javax.swing.text, but it turns out 
> that it was a necessary import after all.
> Further, it also illustrates that it is difficult to create 
> Import-Package declarations by hand, since we cannot always "see" the 
> dependencies. This argues for the use of tools, such as btool (by 
> Peter Kriens) and mangen (by Rob Walker), that both correctly detect 
> this implicit dependency. I wish I would have tested with mangen first!
> Why is all of this encouraging? Because this, combined with the fact 
> that John Conlon's Swing LAF example were both solvable with strict 
> modularity, means that we might not be so far off from a modularity 
> standpoint.
> So, if we implement more verbose diagnostics messages when a class 
> loading error occurs combined with the checks already in Felix to try 
> to lessen other class loading situations, then we might have a strong 
> case for setting the default configuration of Felix to strict settings 
> with no delegation...at least until we get more feedback.
> And, of course, use mangen for generating your imports! ;-)
> -> richard
> Richard S. Hall wrote:
>> John E. Conlon wrote:
>>> On Wed, 2006-04-12 at 05:30 -0400, Richard S. Hall wrote:
>>>> Nick_Hofstede@inventivedesigners.com wrote:
>>>>>> Perhaps there are other possible diagnostics that could help 
>>>>>> developers
>>>>>> when they encounter a class loading error.
>>>>>> -> richard
>>>>> Sounds like a very good idea to me.
>>>>> I also think the suggested checks cover most cases, but I'll try 
>>>>> to think
>>>>> of other cases we might check for.
>>>>> Still the danger of people adding things to the boot delegation 
>>>>> property
>>>>> while they could've/should've made it work without it, but that 
>>>>> can't be
>>>>> helped I'm afraid.
>>> Have the latest release and have tested the
>>> org.osgi.framework.bootdelegation property - it 'works' fine.
>>> Note: if this property was previously implemented and set to the 
>>> current
>>> default of org.osgi.framework.bootdelegation=sun.*,com.sun.*
>>> I would not have experienced the problem and the associated stress and
>>> so would not have sent an email, learned my lesson, and joined the mod
>>> squad. Instead when encountering my classloading problems with javax.*
>>> packages in a rush I would probably have set it to 
>>> org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.*
>>> to avoid cleaning up my non-modular bundles with the correct imports
>>> declarations.
>>> In retrospect I am thankful for the learning experience and recognizing
>>> the advantages will now set it to:
>>> # org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.*
>>> Perhaps the should be the default?
>> This has been what I was mulling over too...and this might be 
>> possible if we create really, really detailed error messages with 
>> diagnostics when you get a class loading error, which is what I am 
>> working on right now.
>> -> richard


Ascert - Taking systems to the Edge
+44 (0)20 7488 3470

View raw message