"Richard S. Hall" <[EMAIL PROTECTED]> wrote on 11/04/2006 11:25:42:
> [EMAIL PROTECTED] wrote:
> > "Richard S. Hall" <[EMAIL PROTECTED]> wrote on 11/04/2006 10:20:28:
> >
> >> I am sure there is room for a big debate here, but delegating nearly
> >> everything on the class path by default just does not seem like the
best
> >> approach to me. I would rather be conservative and let other people
> >> loosen it for their own purposes, then to just ship with it nearly
wide
> >> open.
> >
> > Fair enough, it's just that if you need classes from those packages
you'll
> > be adding them sooner or later due to them being non-modular. It might
save
> > people some head-scratching if classes we know don't play nice are
> > delegated out of the box (like we're about to do with sun.* and
com.sun.*).
>
> I agree that it is probably better to deal with ones that are particular
> problematic, but not all packages in the JRE libraries lead to
> problems...some certainly do.
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.
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.
> Originally, Swing was particularly problematic, for example, but a check
> added to Felix made it possible to detect many situations...however,
> there are still some situations where it is not possible to detect. So
> far, in these remaining cases, the problem can be solved by having the
> bundle import the Swing package that it needs access to, even though it
> doesn't use it directly.
> This is kind of ugly, but the alternative is to
> simply delegate all of Swing, in which case we would have no way of know
> that a bundle hand a Swing dependency at all.
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.
> 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.
> > On the other hand, head-scratching might lead to a better understanding
of
> > the problems and solutions (In which case we might not want to add
sun.*
> > and com.sun.*).
>
> That was precisely my thinking too, that I would rather know the issues
> that we are up against rather than hiding them all. I was debating
> whether or not we should include sun.* and com.sun.* by default too, but
> I didn't want to be too much of a purist. ;-)
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.
> > Also, I don't think people are going to write modular bundles/classes
and
> > put them in any of the specified packages, so adding them shouldn't
cause
> > too much problems.
>
> I am not sure I totally understand this point.
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.
Nick
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
