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:
[EMAIL PROTECTED] 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
