commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nacho Gonzalez Mac Dowell <na...@visual-ma.com>
Subject Re: [lang] Java 5
Date Mon, 16 Jun 2008 08:47:21 GMT
simon escribió:
> 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.
>   
I don't see why anyone would like to import two different 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...

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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>   


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


Mime
View raw message