---- sebb <[EMAIL PROTECTED]> schrieb:
> On 22/01/2008, Jörg Schaible <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to