Last month we had a new JSR vote, which was an initial approval vote for JSR 357. As noted by the Java community at large, we voted no on this JSR and this blog post explains why as per our openness and transparency policy.
The vote itself was an initial ballot approval vote. This kind of vote happens at the very start of the JSR process in order to determine whether or not to accept the concept of a JSR from the initial specification. The JSR 357 proposal defines a social media API for use by Java programs.
Our vote shouldn’t be construed as a negative comment upon the medium term benefits of standardization in the social media space, but rather the immaturity of the area and potential issues within the initial specification of the JSR. The key problem that we see is that the API contains a high degree of domain modelling which is too inflexible to easily accommodate the evolving space.
The lack of focus on mobile is also a significant drawback – in 2012, social media is increasingly being driven by mobile applications – it makes no sense to have a social JSR which is not co-ordinated with the ME standards process. Fundamentally the scope of this JSR is quite wide and its our belief that focussed JSRs make better standards than specifications that are very broad in scope.
These initial concerns were raised by the LJC with respect to this JSR and feedback was given to the Expert Group leads about these concerns which they failed to address within the appropriate time. It was therefore decided that it was inappropriate to assume that these concerns would be addressed during the lifecycle of the JSR so we voted No. A majority of other EC members also voted no to this proposal, thus ending the JSR for the time being. The only EC member who had a direct business interest in social media, Twitter, abstained and echo’d the concerns outlined by the LJC. Furthermore some of the EC members who voted yes, for example Goldman Sachs and Oracle, agreed with the concerns raised but simply felt that the JSR would be able to evolve away from its initial specification during its lifetime and that these issues could be considered again at an Early Draft Review.
We’re very please to see that the Spec lead Antoine has taken the feedback on board and is looking to run a OSS project in order to flesh out this space. Please do join him and the other project members on their Google Group.
Richard (On behalf on the LJC JCP Committee)