source : http://underlap.blogspot.com/2007/03/state-of-java-modularity.html
People are pretty perceptive. They have picked up that there's a
struggle to work out the right model for Java modularity. However, it's
not a simple choice between JSR 277 and JSR 291 as many seem to think.
Let's look at what's going on in a bit more depth.
Firstly, a brief recap for the uninitiated.
JSR 277 is trying to create a static module system for Java 7. JSR 291 is referencing and extending the already mature OSGi dynamic component system while maintaining compatibility with JSR 232 which did a similar thing for Java ME. JSR 294, an offshoot of JSR 277, is focused on the VM and language support for modularity.
personal involvement is that I belong to the JSR 277 Expert Group (but
cannot disclose the discussions which are private to the group) and am
the spec. lead of JSR 291 (which has an openly readable mailing list). I am also in the JSR 294 Expert Group, which hasn't started work yet.
Secondly, I want to be up front about my potential bias.
have been involved in the OSGi Core Platform Expert Group for a couple
of years during which time I co-authored some of the modularity
improvements for OSGi R4 with Richard Hall (the leader of the Apache Felix OSGi project).
work for IBM which belongs to the OSGi Alliance and which has based
some of its products on OSGi. IBM and Sun co-operate on Java, but
compete in related areas such as Java EE, not to mention UNIX-style
operating systems and hardware. So IBM and Sun don't necessarily agree
on everything that happens in Java. In fact, I think it would be pretty
unhealthy if that were the case.
I should also re-iterate that my opinions are not necessarily shared by IBM.
That said, I'll try to lay out what's going on as objectively as I can.