commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <simon.kitch...@chello.at>
Subject Re: Support for OSGi
Date Tue, 22 Jan 2008 13:02:06 GMT
---- sebb <sebbaz@gmail.com> schrieb:
> On 22/01/2008, Jörg Schaible <Joerg.Schaible@elsag-solutions.com> wrote:
> > Mark Proctor wrote:
> > > Torsten Curdt wrote:
> > >>
> > >> On 21.01.2008, at 10:08, Tom Schindl wrote:
> > >>
> > >>> Hi Torsten,
> > >>>
> > >>> I understand this but we are seeing many J2EE-Servers adopting OSGi
> > >>> and many applications (I admit most of them in Eclipse-world) also.
> > >>> It seems strange to me in those envs to use this "artificial"
> > >>> package to overcome jar-hell (which is the only reason for the
> > >>> java5-package right?) they are not having
> > >>> because of OSGi.
> > >>
> > >> Hm.... not sure why its such a big deal to have e.g.
> > >> o.a.commons.lang2 or similar. If you use an IDE that manages imports
> > >> you will barely notice anyway.
> > > personally I've always wondered why having a version attached to the
> > > namespace hasn't taken off more to deal with api breaking
> > > releases. if
> > > we had org.antlr1 org.antlr2 org.antlr3 life would be much
> > > easier. Sure
> > > you wouldn't get auto drop in jar and release, but I'm
> > > guessing tooling
> > > could make up for that in those cases.
> >
> > Ironically Java could already support this, there's a reason why a manifest should
specify a Specification-Version. It would have been so simple to use this information also
to separate classes in a class loader. But the Gods of Java refused to make anything out of
it ;-)
> >
> 
> Surely that would not work for java classes without a manifest - e.g.
> classes which are loaded as individual class files rather than from
> jars. Not all Java processes use jars.

And there are limits to jar isolation anyway.

If one library returns an instance of o.a.c.foo.Foo from v1.0 of the foo library, and another
library expects an instance of o.a.c.foo.Foo from v2.0 of the foo library, then no "isolation"
will help; the two libs are just incompatible and there is no way AFAICT to write code that
will call the first method and pass the result into the second method.

Using package-name changes, one would return o.a.c.foo1.Foo, while the other would take an
o.a.c.foo2.Foo which is inconvenient but can actually be handled.

I don't know how OSGi handles this sort of issue..

Regards,

Simon

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


Mime
View raw message