felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Fixed bug in class loading
Date Tue, 11 Apr 2006 12:14:02 GMT
Nick_Hofstede@inventivedesigners.com wrote:
> The list might be too long, but I wouldn't be surprised if it's possible to
> create an example for all of the packages in
> org.osgi.framework.system.packages listed there. They might still not
> warrant the blatant delegation in org.osgi.framework.bootdelegation, but it
> won't be far off.

That still remains to be seen, but it doesn't make sense from my point 
of view to just accept the worse case from the beginning.

> Maybe we should go through them one by one. Maybe we should just wait until
> someone complains (as happened now). Maybe we should keep the default empty
> and let the user add the things he need.

I prefer getting some experience by people complaining and looking at 
the cases that arise to determine the best way to solve the issue.

> I did not know this, and I agree it feels kind of ugly. Maybe we should add
> all delegeted packages to the export-list of the root bundle. That way the
> bundle can import the Swing package indicating the dependency.
> Seems like a good way to handle this actually.

There are two reasons not to delegate to the parent:

   1. Improves WORA of bundles, since all of their dependencies are
   2. Makes it possible to use bundles to replace packages on the class

The approach you describe seems to be the path that Equinox has chosen 
to deal with this issue. While I agree that it is better approach is 
better than delegating only, since it makes it possible for a bundle to 
explicitly declare its dependencies, it is still not a requirement that 
it does so, thus any bundle can chose (or forget) to do it and then 
there is no way to know that the dependency exists.

Additionally, it creates the false sense of modularity, since it makes 
it appear that importing/exporting such packages actually does 
something, but in reality the declarations are just for show, since all 
such requests are simply delegated. For example, a bundle may come along 
with its own improved Swing implementation (maybe we could use GNU 
Classpath or something, remember the days when Swing was a separate 
JAR?), but no bundles could ever use that implementation even if they 
were wired to it by the framework resolver, since their javax.swing.* 
requests would all get delegated to the parent before the new Swing 
implementation had a chance to answer their requests.

>> Continuing with Swing as an example, since it is possible to use Swing
>> in many cases without causing too many problems by not delegating, it
>> makes sense to me to not delegate for it by default.
> I now think delegating all of swing and adding it to the export list of the
> root bundle seems like a good idea.

I disagree for the reasons stated previously and above.

> I do find some sadistic pleasure in forcing other people to relive every
> problem I once faced, but I also think we should consider making it easier
> for them.
> Adding some of the packages seems like a bad middle ground. A commented out
> default (perhaps with a comment why you might want to delegate this or that
> package) might be better. Just an idea.

By delegating everything to parent we just force people into facing 
other problems. I don't think there is a win in this situation. One 
thing to keep in mind, many of these issues are particular to the Sun 
JVM. Many of these problems do not occur on the IBM JVM, from what I 
understand...although I am sure that some still do.

> I was thinking about what harm it would do to delegate the listed packages.
> I couldn't imagine anyone using those packages for it's own bundle, so
> delegating them shouldn't be too much of a problem. I might be wrong, or
> there might be other reasons why delegating those packages might hurt
> someone, but if it really is pretty harmless, it counts in favor of adding
> them.

Just depends on your definition of "harm" and what your priorities are, 
I guess.

-> richard

View raw message