Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Subject: Re: [lang] Java 5
From: simon <simon.kitching@chello.at>
To: Jakarta Commons Developers List <dev@commons.apache.org>
In-Reply-To: <4852BA3F.9010202@visual-ma.com>
References: <375586.71165.qm@web55108.mail.re4.yahoo.com>
	 <f2e8eedf0806112043y5b45d231wdfa0899466e1730d@mail.gmail.com>
	 <4850CB06.5020205@chello.at> <4850D32C.6060301@bestsolution.at>
	 <4850D716.4020402@chello.at>  <4852BA3F.9010202@visual-ma.com>
Content-Type: text/plain; charset=UTF-8
Date: Fri, 13 Jun 2008 23:19:22 +0200
Message-Id: <1213391962.6233.9.camel@simon-laptop>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit


On Fri, 2008-06-13 at 20:19 +0200, Nacho Gonzalez Mac Dowell wrote:
> simon.kitching@chello.at 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.

> 
> > 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...

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org