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:51:39 GMT
Nacho Gonzalez Mac Dowell escribió:
> 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 *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: 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
>
>


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


Mime
View raw message