Updates on Interoperability

[Sam Pullara]

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.

Sam