[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.
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.
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.
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. ;-)
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.
To be clear, this is not an important issue for me, I'm just pointing out
what other people did and possibly why in this regard.
Yep.
-> richard