BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Rejection of Social Media API by JCP Expert Group Members Sparks Debate On Innovation

Rejection of Social Media API by JCP Expert Group Members Sparks Debate On Innovation

Bookmarks

When the JCP rejected JSR 357 (Social Media API) in an 8 to 5 vote, members criticised it for being too broad in scope and not taking sufficient account of security and the mobile space. However, members favouring the proposal indicated this was a political move and impedes innovation. "I have worked in the Executive Committee (EC) since 2008 and have been a JCP and Expert Group (EG) member since 2005 so, especially in the EC, I constantly observe these issues and reasons, I don't just assume it or infer it," specification lead Werner Keil told InfoQ. "One of my predecessors as ME EC Member, Jean-Marie Dautelle, had reasons to not run for an EC post again, similar to Sean Sheedy, all related to a more political or legal, and less technical or often logical, way such decisions are made."

The need for a standard Social API for Java has been discussed for some time. As far back as the Executive Committee Face to Face Meeting in Bonn, in October 2010, Oracle was arguing that Java ME should incorporate a Social Networking interface, thereby allowing

...applications and local web services (servlets) to interface and host 3rd party social applications (e.g. hi5, LinkedIn, MySpace, Netlog, Ning, orkut, XING, Yahoo! ...) like OpenSocial.

JSR 357 struggled to gain much support however. Of the 16 members of the Executive Committee, only five (Credit Suisse, Goldman Sachs, Red Hat, Oracle and SouJava) voted in favour of the proposal. Eight members voted against (Azul Systems, Eclipse Foundation, Ericsson, Google, HP, IBM, London Java Community and SAP), whilst Fujitsu and Twitter abstained and Intel did not vote. In general, the JSR was criticised for having too broad a scope, even by those voting in favour.

As Credit Suisse represents the customer's point of view in the Executive Committee, 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.

Twitter, who abstained, and others also made the point that it was perhaps premature to be attempting a standard.

While we were initially excited about this proposal, we think it's a bit 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.

Of the no votes, the London Java Community (LJC) commented

Whilst the LJC applauds the efforts to build a consensus around the social media space, we feel that this proposal has significant shortcomings and as such, we are unable to support it at this time.

The key problem that we see is that the API contains a high degree of domain modeling 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 coordinated with the ME standards process. The LJC would welcome the withdrawal of this proposal, and its replacement with smaller JSRs which target specific parts of this space instead.

InfoQ spoke to Ben Evans, who is the London Java Community representative on the Executive Committee, and he also expressed concern that the proposal didn't place enough emphasis on mobile.

The proposal was discussed at the January Face to Face in Redwood Shores. There was a lot of feedback about the proposal, including forms of a lot of the specific criticism that was presented by EC members in their comments on JSR 357. The LJC's feeling was that feedback from the EC meeting was not incorporated into the draft that was ultimately submitted for consideration - and that boded ill for the progress of the JSR as a whole. In particular, JSR 357 was submitted as an SE/EE spec, with no real emphasis placed on mobile. Although platform convergence is happening, it is still a long way off, and social is a space which has a great deal to do with mobile.

Keil suggested to InfoQ that IBM's decision to vote no at a very early stage in the process may well have influenced others, and that given that IBM had recently sold 750 patents to Facebook, at least according to Bloomberg, they may have a political agenda. His co-spec lead Antoine Sabot-Durand, who also leads Red Hat's Seam Social, does not share this analysis however. "I think the JSR was voted down for four reasons," he told InfoQ.

1) New JSR type
Most of the JSRs so far are dealing with technical aspects of development (shareable components, ORM, transactions, Web Service), whilst our JSR is one of the first (including JSR 351 perhaps) dealing with high level issues and using transverse technologies (JAX-RS 2.0, JSONP, CDI, JSR 351 to name just a few). As it's not in the JCP culture we had to be more precise and work more on pedagogy.

2) Too soon
Most of the technology needed for Java Social was not developed yet : especially JAX-RS 2.0 (and the client framework) and JSONP. So we were building a standard on non-existing standards.

3) No real Proof of concept
In the past years, great JSRs followed a new path that gave successful technology. This path is implementation before standardization. To name two of these: TopLink and Hibernate gave JPA, Seam 2 and Guice lead to CDI and JSR 330. Seam Social wasn't ready to be this POC. So I think we should build an Open Source solution used by a lot of people and then go for standardization

4) Not enough preparation
Finally, we should have worked more at this proposal to make it more focused and with a visible scope.

Both Sabot-Durand and Keil made the point that, whilst the social vendor space is still very dynamic, the Social Media API hasn't come out of a vacuum. As well as the aforementioned Seam Social, which builds on CDI, there is DaliCore, which shares a lot of aspects with Sun's own (now defunct) SocialSite, and Apache Rave, which recently became a top-level project - although it depends on Wookie, which itself remains in incubation. Other products and APIs include eXo Social, VMware's Spring Social, and Twitter4J, an unofficial Java library for the Twitter API. Despite this though, there isn't thus far a sense of a common or dominant approach emerging, and the JSR specification would almost certainly have needed to be quite inventive. In view of this, the decision to reject the JSR has reignited the debate about whether the JCP can and should be used to foster innovation.

Azul Systems, who recently joined the JCP, was one of the organizations who rejected the the proposal. InfoQ spoke to their JCP representative and CTO, Gil Tene, about his reasoning.

InfoQ: What role do you see for innovation and the driving of new standards within the JCP and through JSRs?

I think the JCP should innovate in areas that are under its control and scope, and for which it can assemble credible expert groups that lead the industry in the subject matter involved. I also think the JCP should not attempt to innovate outside of those boundaries.  I see productive JSR work as falling into three main categories:

a) defining and expanding the Java platform.
Defining, expanding and improving the core Java platform is a key role of the JCP. New language and runtime features, new ways of increasing programmer productivity, and even providing for other, non-Java, languages to share the same runtime platform all fall within this mandate, and there is plenty of room for new and innovative ideas in this space. While great ideas can be borrowed from other areas, such work will not be done for us by other bodies.

b) Adopting and interfacing with externally led non-platform-specific standards, and following established industry innovations. E.g. XML, HTTP, SCTP, JSON, OSGi, etc.

c) Innovating in areas where a vacuum exists, where the Java platform provides a good place to build new capabilities not yet available for the industry as a whole, and where the JCP can get credible domain experts and industry leaders to define useful standards that other bodies are not naturally trying to standardize outside of a platform-specific environment. E.g. Java EE & new container types.

There is plenty of room and work to do in the first and third categories above. Having the JCP try to standardize things that reach far beyond the Java platform and are in a state of flux is, in my opinion, fundamentally wrong, and will just end up with a standard nobody uses. When industry efforts already exist to stabilize, model and standardize behavior, the JCP's role is clearly to follow and not to lead. Imagine the JCP trying to standardize XML while "in flux", and before W3G decided what the standards look like. Or attempting to standardize SCTP before IETF drafts seemed stable.

InfoQ: Do you think that Social Media is not worthy of a Java API?

We would be very excited to see a Social Media API for Java, but this falls clearly in the second category of JSRs I noted before. I think that such API portions should only be standardized after the dust settles on the work other bodies and communities are actively doing, and when there appears to be some stable agreement on what an initial version of a Social Media API (that is not specifically tied to or limited to the Java platform) would model and include. For example, a standardized Java Social Media API that does not actually interact with and successfully model Social mediums such as FaceBook, Twitter, Google+ and LinkedIn would be "silly", and would be immediately obsolete.

The evolution of common models, and of APIs that allow for such interaction, is still ahead for the industry as a whole. I believe that the JCP is not the right place to lead such an industry-wide effort. It is the right place to follow one when it appears to be on the way to actual success. I do think that there are some narrow aspects of Social Media interactions that are already well understood, and for which stable common denominators are already forming. I would support a JSR that focused on following such externally lead efforts and establishing the Java platform syntax and repertoire for interacting with them.

In my opinion, that is not what JSR 357 proposed. Its goals, perceived needs, and proposed scope appeared to go far beyond interacting with existing mediums and using established interfaces. You can read the specification request at http://jcp.org/en/jsr/detail?id=357 and judge for yourself.

I think that it is telling that neither of the two current JCP EC members with the most relevant industry footprint in this area: Twitter and Google, chose to vote in support of the JSR proposal as stated. Without the support of such players, a standardization attempt would be doomed from the start. I hope to see a JSR proposal in the future that these members and other industry stakeholders can support.

InfoQ: Do you think that the standardization of such APIs can or should work to prohibit underlying proprietary implementations and vendor lock-in?

One of the issues that concerned me most about the proposed reach of JSR 357; its answer to the question, "Why isn't this need met by existing specifications?" Specifically the statement,"... However, most of these built on top of quasi-standards or proprietary technologies adding the risk of a vendor lock-in even if the API itself may be provided Free or Open Source ...".

While I strongly support Open Source, and advocate for enabling nonproprietary implementations of standards, I don't think that for the JCP to mandate Open Source implementations would make any more sense than if it were to prohibit them. The role of a standard is to allow multiple competing implementations to maintain compatibility and to reliably interact. This includes proprietary, closed, costly and tightly licensed implementations as much as it does various openly developed, free and/or open source licensed ones. I would not want to see either implementation model prohibited by a standards body.

As for vendor lock-in, that's something for the users of the various technologies to ultimately decide. I certainly prefer a world where multiple choices exist with easy mobility between them, but that is not something you can effectively force to happen with a standard. By its very nature, a standard suggests the enabling of more than one implementation, and hence a choice. A healthy, vibrant ecosystem can certainly develop when multiple choices exist. But it can also evolve when, at least for a period of time, a common, single choice is so readily and freely available that people do not care about choice and embrace the "sameness". That sort of thing usually lasts until the next disruption, or until the readily available single choice falls behind in some way, driving us to real "choice" again.

Whilst not wanting to comment on the relative merits of this particular JSR, JCP chairman Patrick Curran expressed a similar sentiment about the things that a standards body should or should not innovate in.

It's not usually a good idea to innovate within a standards organization since, once defined, standards by definition need to remain stable. In other words, you need to get it right first time. If you try to standardize in an area where the technology is rapidly changing or where there is a lack of general consensus about the technical approach that should be taken, then you are unlikely to get it right first time, and you will either have to make major - and probably incompatible - changes further down the road, or risk having your standard ignored as the industry moves on.

The safer approach is to innovate outside of the standardization process until a broad consensus is reached, and at least one - and preferably more than one - implementation is in widespread use. A standardization effort at this point is much more likely to succeed.

This approach has led to a number of successful APIs being introduced into Java, such as CDI and JPA, as Sabot-Durand noted earlier. Moreover, with OpenJDK now the reference implementation for Java itself, this is increasingly how Java language innovation is done.

Sabot-Durand made the related point that innovation within the standards body often results in failure.

The JCP is a standardization organization not an R&D lab. I don't think its role is to drive innovation, but to validate it. For a long time, the JCP tried to create innovation by creating important Specifications before implementing them. EJB 1.X and 2.X are examples of this "innovation" driven by the JCP : failure.

Around 2002/2003, the JCP changed its policy and now prefers to take innovation from the Open Source world and standardize it.

Standardization can be an impediment for innovation. That's the main reproach people level at the JCP: "If I start my project with Java EE I'll be stuck for 4 years with this bunch of technologies waiting for the JCP to deliver the next Java EE version".

That's where a specification like CDI plays its role: it allows developers to create technical and functional portable extensions for the standard and allows them to make it evolve between Java EE versions. It's an engine to extend the standard and bring innovations in the JCP. It's the main reason why I joined the Seam 3 team and now the Apache DeltaSpike project. Most Java innovation will be born there.

The alternative, as Curran states, is to get it right first time, but that rarely happens in practice. For an example, consider Joda-Time, a widely used and popular replacement for Java's date API, but Stephen Colebourne, its author, has stated that it "has design flaws" - and thus the new date and time API for Java (JSR 310) isn't simply Joda-Time as a JSR.

Not everyone agrees though. Writing on his blog, Expert Group nominee Markus Eisele, a principal technology consultant working for msg systems, took a different line.

I for myself am not sure if this is the right way to go with the JCP in general. If it is common sense to only adopt what is already out there the JCP will fall behind recent developments and trends even faster than it already did in the past. And it always will follow some kind of documenting the status quo approach.

InfoQ spoke to Eisele to find out more about his thoughts. Whilst accepting that things aren't quite as black and white as his blog post implies, he did argue that the JCP should make more of an effort to support innovation.

Let me step back one more step and look at standardization in the industry in general. You can find some interesting posts (one, two three) about the history of specific standards bodies (ANSI, ISO, and more). They all share a common topic: Standardization is the collaborative production and dissemination of technical knowledge.

Further on, the DIN EN 45020 defines the term "standard" as a "document, established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context".

The antagonism here is that you need free space for innovation, while standardization is generally aiming at convergence and efficient procedures and tools. One might feel that having a standard in place is the end of innovation in that particular field. And looking at Patrick's comment, you might get the impression that there has been no need [for innovation] at all in the past.

Let's turn that around and look at the "stakeholders". What about people developing and using standards? Compared to what other standard bodies do, the JCP is in line with them. Proposed standards can be submitted by any JCP member and once accepted a standardization project is responsible for involving the relevant and interested parties. One major difference here is that most of the official standardization organisations aim to have a much broader stakeholder base. Looking at the JCP ECs at the moment you mainly see two categories - vendors and consumers. Looking back at the words "collaborative" and "dissemination" this seems to be a big shortcoming here. What about research, universities, government, independent experts? And I am also throwing in the old story about Doug Lea leaving the JCP. Let me cite him here:

"I believe that the JCP is no longer a credible specification and standards body [...] Sun initially placed in the JSPA and Process documents enough rules to ensure that the JCP could foster innovation [...] However, some of these rules, and violations of rules, have been found to be the source of stalemates and lost technical ground."

That does sound familiar, right? Even if he is declining the complete JCP and I am only criticising a part of it. Let me make this little difference very clear: The JCP in general is a working standards body to me. From the organizational point of view the truth is that, with the current mix on the Executive Committees, there is hardly any chance for real technical innovation. We are missing the right stakeholders for that. I assume that none of the vendors on the EC have a huge interest in agreeing on "common and repeated use" guidelines, as long as they can make sufficient money out of their own proprietary solutions. And to be honest, there is nobody to blame for that. Even I personally probably wouldn't act very differently being in such a comfortable situation.

Given that, I strongly believe that the JCP has to find a way to handle innovation in the right way again. It's not only there to consolidate the work that has been done in the past. The JCP covers the characteristics of a whole language eco-system and it is essential to actively drive innovation from it. I can imagine a couple of ways to foster this. One simple idea would be to simply add more diversity to the EC. This movement has already started with the JUGs joining the JCP and having SouJava on the EC, but we are far from having a healthy mix here. Given that all JCP work is of a voluntary nature, there is a big hurdle for many individuals and even R&D people to jump on it. A way needs to be found to remove this hurdle. Another idea could be to split the process into different ECs (or have supporting boards) with different responsibilities. One could be the technical board while the other takes care of political issues.

All this is more or less my own brainstorming and not much thought over until today. And I might not be the right one to propose a new structure here. But I love to push Oracle to come up with more ideas.

Oracle is, of course, already working to reform the JCP, as we've discussed previously. JSR 348 began that process, and JSR 355 will look to combine the two JCP Executive Committees. Beyond that, a third JSR is planned to look at the complex issues around IP and licensing rights, which were at the heart of the dispute between Sun Microsystems and the Apache Software Foundation, and which ultimately resulted in Apache leaving the JCP.

Whilst Keil and Sabot-Durand could re-submit their plans within 14 days under the rules of the JCP, they told InfoQ that they won't do so. Rather, they will delay until JSR 355 merges the two Executive Committees. Keil told us

A merged EC, already initiated by the JSR 355 reforms, will look slightly different. While some rules, e.g. the minimum number of "Yes" votes you need for a JSR, are the same, there is then just one "pool" of votes, who have to find a single majority towards a decision; not two. At the moment this is almost like the US Senate and House of Representatives, and US politics constantly demonstrates to us how "effectively" those two usually work together, especially if each of them is dominated by different parties or ideologies.

Thus, the more emphasis we put on Mobile the more sense it could make to skip the 14 days and try again, maybe between 7 and 14 months hence.

It is worth noting that the decision to reject this JSR has had some other implications. eXo told us

eXo planned to join the JCP as a commercial Member to participate in JSR 357 if this JSR were accepted (Alain De France, would represent eXo for this JSR). If another proposal is done and accepted on that subject, eXo will join the JCP to actively work on it.

In the end though this delay may prove beneficial to both sides. It should give more time for Seam Social and others to explore the problem as Open Source projects, before another attempt at standardization is made, and that in turn could result in a better standard. As Ben Evans put it to us during our conversation,

We'd be happy to see Antoine Sabot-Durand run a successful F/OSS project in this space with a view to running a smaller JSR once he's got a thriving project.

 

Rate this Article

Adoption
Style

BT