Updates on Interoperability

[Richard S. Hall]

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 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.

However, that isn't the way we have been going, nor has it ever been as 
far as I am aware.

-> richard
>
> Sam