Updates on Interoperability

[Richard S. Hall]

Sam Pullara wrote:
> On Apr 25, 2008, at 5:19 PM, Richard S. Hall wrote:
>> Sam Pullara wrote:
>>> On Apr 25, 2008, at 4:46 PM, Richard S. Hall wrote:
>>>> Sam Pullara wrote:
>>>>> The vast majority of people that are going to use this system will 
>>>>> have never heard of OSGI nor care about any of their more subtle 
>>>>> features and just want an easy way to leverage the vast amount of 
>>>>> libraries available (virtually all of them are not OSGi modules 
>>>>> today but are jar files in maven repositories).  We shouldn't be 
>>>>> specing out some sort of uber container but rather a simple way to 
>>>>> tie code to its dependencies.
>>>>
>>>> If this is all that people wanted, then we could just define 
>>>> repositories and associated metadata and forget about all runtime 
>>>> modularity support, but I strongly disagree that this is all people 
>>>> want or else there wouldn't be such an upsurge in OSGi interest and 
>>>> adoption.
>>>
>>> I guess that is what I am arguing for.  I don't see the critical 
>>> need, outside the internals of application servers and a very few 
>>> plugin based tools, for runtime modularity support.  And if OSGi can 
>>> load a JSR-277 module then I feel like the interoperability job is 
>>> done.
>>
>> I can understand your point of view, but I think you need to take a 
>> look around and see what kind of systems out there are creating 
>> either their own plugin mechanism or using an existing framework 
>> (like OSGi) to create a plugin mechanism. This is a huge area. It is 
>> actually one of the biggest impacts that Java made with its class 
>> loader approach, it brought code loading to the masses.
>
>> I could give countless examples that fall outside the "few tools" 
>> above (heck, today I just ran across a gaming platform using OSGi), 
>> but I won't go into that.
>
> I have no problem with them using OSGi and I think it has a lot of 
> value.  It just doesn't seem like you need to make it built into Java 
> but rather another container specification.
>
>> I might wholeheartedly accept your view if the powers to be decided 
>> to pare down 277 to be just a repository model for Java JAR files, 
>> because that could potentially be fairly easy for us to specify and 
>> get working as an OSGi module repository (which is currently 
>> lacking). I have said before that it makes sense to have 294 give us 
>> needed VM support for modules, 277 give us repository support for 
>> modules, and 291 give us run-time support for modules.
>
> This seems like a good plan.  We'd have no problem wrapping this up 
> quickly with this as the goal.
>
>> However, that isn't the way we have been going, nor has it ever been 
>> as far as I am aware.
>
> I agree. I've been trying to push us this way since the beginning. 
> Unfortunately, me: FAIL.

Join the club...

-> richard

>
> Sam