Nacho Gonzalez Mac Dowell escribió:
simon escribió:
On Fri, 2008-06-13 at 20:19 +0200, Nacho Gonzalez Mac Dowell wrote:
[EMAIL PROTECTED] escribió:
Tom Schindl schrieb:
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
Yep. Well, it works for those libs that are just internal
implementation
details.
I'm not an OSGi expert, but if any exported class contains a public or
protected method that has type T as a parameter or return type, then
aren't you again locked into a single application-wide version of the
lib that provides T?
In OSGi you have a different class loader for each bundle making
this possible. Think of Eclipse (currently I work with Equinox).
Bundle (plugin) X can be using ASM version x.x and Bundle Y can use
ASM version x.y. Unless Bundle Y depends on Bundle X and Bundle X
exposes the conflicting packages of ASM (which is a really bad idea)
then you are safe from the headaches you are talking about. Further
on, if you create two bundles with ASM (version x.x and version x.y)
you can specify that Bundle X uses ASM version x.x and that Bundle Y
uses version x.y of ASM with out any problems.
I think this is rephrasing what I said, isn't it? With OSGi,
dependencies which are *not* exported as part of a bundle's public api
can be completely hidden from other stuff in the app.
This solves *half* the "jar hell" problem. Which is nice.
I don't see why anyone would like to import two different *versions of
the same* bundles onto a single bundle. As I've said before I use a
different version of ASM on the very same app. The thing is that I
have modularised my app so that there is no problem with this. IMHO
OSGi goes far beyond (truly) solving the "jar hell" problem, like
forcing you to modularise your app properly. But I think this is
getting a bit off topic...
Sorry, I meant "I don't see why anyone would like to import two
different *versions of the same* bundles onto a single bundle."
On the other hand, the question is "can you rely on people using
OSGi?" and the simple answer is no (at least not yet). So it probably
does make sense to change the package name.
If so, then OSGi will solve problems for things like ASM which are
usually pure internal details, but will not solve problems for things
like commons libs whose types are commonly part of another lib's
exported API (lang.enums.Enum, lang.math.DoubleRange, etc)...
Obviestly, for java reserved words, this is a dead end. You need to
change package names.
Who said anything about reserved words here? The word "enum" is
reserved, but neither "enums" nor "Enum" are...
You are right. Sorry, I just read wrong...
The second part of the "jar hell" problem is dependencies which *are*
exported as part of a bundle's public API.
For example, a bundle exports a class with this API:
public boolean isInRange(
org.apache.lang.math.DoubleRange range,
double val);
Now doesn't loading that bundle in an OSGi app limit the entire app to
having just one common version of lang, just like a non-OSGi app would
be?
I'd love to be wrong - it would be cool to solve that problem somehow.
But I cannot see how that would be possible. So as far as I know, OSGi
solves just half the jar hell problem, and we (lib writers) still need
to preserve binary compatibility even between major releases - or change
package names.
Regards,
Simon
Best regards,
n
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
