JSR Watch

JCP Executive Committee fail to back Social Media API

Chris Mayer

JSR 357 – Social Media API proposed by Werner Keil isn’t approved by JCP after raising concerns over scope of project. Java isn’t jumping on a standardised social media bandwagon yet.

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,

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

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. 

comments powered by Disqus