The "rubberstamping" aspect could be a problem because the JSR is basically a repeat of the normal OSGi specification, which means that instead of the development of a dynamic component JSR, one is simply being imported. That calls into question the worthiness of the JSR in the first place, as OSGi is quite able to stand on its own without JCP approval.
An example of the voting committee's concerns with the rubberstamping aspect, from JBoss (who voted no):
We fail to see the need for this work to be rubberstamped within the JCP process. If it cannot be simply referenced by some other JSR, then it's relevancy is immediately called into question. If the OSGi work is sufficiently well formed that no further input is required by JCP members, then why not have a 2 page JSR that simply says "Go to the OGSi site if you need this capability". If it really requires a more indepth specification, then we should be allowed to modify the work as it progresses through JCP.Other members voted "Yes," despite some of the same concerns.
The overlap with JSR-277 comes into play because of JSR-291's aggressive timeline, which means that instead of having OSGi represented on the 277 expert group, it could be expected that JSR-277 should leverage JSR-291, as opposed to developing as a module system with input from the OSGi experts on the Expert Group, without an existing JSR imposing any stronger restrictions.
As an example of some of the concerns with the overlap between JSRs 277 and 291, Google (who also voted No) had this comment:
Google is concerned about the relationship between JSR-277 and JSR-291. JSR-277 defines the core platform's approach to modularity, an area that is crucial to the continuing success of the Java platform. We are confident of JSR-277's success, but worried about the possible effects of further constraints. We are sympathetic to JCP standardization of OSGi standards, but we believe that this task is best undertaken after the underlying foundations have been established by JSR-277.It should be noted that despite the concerns being most clearly explained in comments by voters who rejected the JSR's approval, the concerns were echoed by some who approved the JSR, such as Borland, Nortel, Oracle, Apache, and Intel.
What do you think?