[EMAIL PROTECTED] 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
explicit.
2. Makes it possible to use bundles to replace packages on the class
path.
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
