Updates on Interoperability
sam at SAMPULLARA.COM
Fri Apr 25 17:28:36 PDT 2008
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.
More information about the jsr277-eg-observer