JCP Executive Committee fail to back Social Media API
The votes have been cast and verified, and the JCP can now reveal that the proposed Social Media API for Java SE and Java EE has not been approved at the Review Ballot stage.
The jury who approve Java specifications were fairly split in their decision over the merits of the Social Media API proposed by Werner Keil, right at the beginning of March.
Whilst many recognised the need for a social media renewal, many voiced concerns over the sheer scope of the task, saying it simply wasn't possible to fit it all into a workable specification that would be adopted by the wider Java community.
IBM was certainly the most vociferous over the Social Media API, stating:
At present, the environment around social media programming models is characterized by very rapid evolution in open standards communities like the OpenSocial Foundation, and open source communities such as Apache Shindig, Abdera2 and Rave. JSR 357 would attempt to place an overarching API structure onto a set of those moving parts.
IBM believes it is too early in the life cycle of the social media environment to put a JSR 357 Java API into the marketplace which would - at best - cause confusion and potentially impede the development of the current broad based work being done.
It's a fair criticism - social media is so in flux that by the time a specification was implemented, it could well be null and void in parts. But Keil did say in the original specification that these communities weren't as active as they once were, nor are they receptive to the everchanging field.
IBM went further, offering an alternative approach:
IBM believes the correct approach is to allow the marketplace to coalesce around the evolving social media models, and as they mature, provide robust Java APIs bindings to provide the Java community with useful "on-ramps" to social applications that provide value to our customers. When the time is right, and the Java community's understanding of Social Media APIs for our customers is more mature, a set of more specific JSR proposals, each addressing a specific area of customer need in Social Media APIs, is the approach IBM would like to see develop.
Others echoed their views, including the London Java Community who said that despite the well-natured intentions of revamping defunct methods, there were 'significant shortcomings' and would prefer an approach that was broken down into smaller JSRs.
Others voting No on JSR 357 included Azul Systems, the Eclipse Foundation, Ericsson AB, Google, Hewlett-Packard and SAP. Some however voting in favour, seeing the merits of the JSR and wanting to push for a social media standardisation.
Credit Suisse offered the following with their vote:
We are interested in converging the various industry standards (Open Social and others) and pushing the standardization for Social Network Technologies also from the JCP. We are concerned about two points: the broad scope mentioned in the request and security. Consequently, we suggest that security implications of the features of the API have to be clearly investigated and appropriate guidelines to securely use and implement the API have to be given.
Interestingly placed in this debate are JCP Executive Committee Member and social media colossus Twitter, who abstained but did say they thought this was 'too early to start standardizing on social and encourage folks to look at third party libraries for support to connect to the myriad of social networks available.'
On reflection, this seems exactly the right decision, due to the changing nature of the medium. Java does need a social media overhaul at some point in the future but with all the intricacies still being fleshed out in how we understand social networks, it's probably best to let third parties deal with it first, without the gold standard stepping in and making mistakes.