JCP – JSR Renew Ballot – 11 May 2015 Results

Today 13 May 2015, the Java Specification Requests Renewal Ballot results have been made public. Several companies and JUGs that compose the Executive Committee for SE/EE voted for the bellow JSRs to continue or to park activities.

JSR 350 – Java State Management
A predicted result, the Executive Committee has not approved this ballot. With 5 Yes, 8 No, 10 Abstain and 2 Not voted.

Several comments are pointing to the problems this JSR is facing:

SouJava voted No
This is the second extension, and we expected the EG to actively engage with the community at large to revive this JSR. This has not happened, and there are no signs of public activity in this JSR. (...) We suggest that EG experiments with other ways of engaging the community, and maybe when things get more concrete, we can reevaluate these ideas in a new JSR.

London Java Community voted No
We don't find their reasons compelling enough and there is not enough public evidence of any meaningful progress. We'd encourage the participants to form an OSS project around this concept and ensure that it is a real use case that the ecosystem at large wants standardised.

RedHat voted No
(...) Red Hat still thinks that standardisation is premature and a risk. We would rather see the energy of the expert group focused on building an open source project (...)

Among several other comments, the feeling is the same.
The EG failed to engage the community to revive this JSR,
and two formerly active participants RedHat and London Java Community withdrawn their support. The community believes this spec is yet not settled and the work could be continued as an OSS project in order to have this standardization more mature and better define the problem space.

A little detail for Azul Systems Inc. and SAP AG both NOT VOTED.

JSR 351 – Java Identity API
With 21 YES, 1 No, 2 Abstain and 1 Not voted.

Several comments have been left stating problems with the organization and alerting that the steps planned to revert this situation are not detailed enough.

SouJava voted Yes
SouJava agrees with concerns posed by others about progress. We are particularly put off by the very empty promise of resuming work when (and possibly if) "these circumstances change". It is not even clear that things can change before a new renewal ballot comes along... All that said we ended up deciding to vote YES for this extension request, in our policy of always giving the EG at least one chance of regrouping and reengaging the community. But we would prefer to see future requests from EGs to be more detailed on concrete steps planned to revert the situation.

Among many other comments, I would give special attention for LJC, the only entity to vote No (Twice for this JSR).

London Java Community voted No
We don't find their reasons compelling enough and there is not enough public evidence of any meaningful progress. We'd encourage the participants to form an OSS project around this concept and ensure that it is a real use case that the ecosystem at large wants standardised.

The LJC comment is very interesting, if we go back in time and read the first renew ballot for the JSR-351 we can understand better the reasons why LJC says this JSR is “not compelling enough” and that “We’d encourage the participants to form an OSS project”

London Java Community voted No:
(...) It is unclear why you would need to standardise the entire domain model, (...) the present form of JSR 351 has several very serious problems.

Firstly it’s very US-centric, e.g. references to social security numbers. Other countries use different identifying codes, for example the National Insurance number in the UK (and many countries have no unique number identifier which would be equivalent to an SSN). It is also unspecified as to what the format of bank account numbers are. In this instance even though there is an international bank identifier, it is rarely used by people when describing their accounts.

Several of the identity attributes JSR 351 mentions (e.g, nationality and gender) are incredibly difficult to define in a manner that is
unambiguous, accurate and precise.
For example, gender is not simply a male/female choice. There are other possibilities which need to be taken into account, for example the possibility that a person doesn’t consider themselves to be aligned with any specific gender (this last possibility is under serious consideration for codification into a number of national data standards, for example the Australian Passport Authority). This poses concerns given the proposed integration of the standard into the Java security model. The expert group should seriously consider the implications of, for example, people being unable to access medical treatment due to security policies predicated upon gender.

Within the current model, the standardisation is then very weak, as validation of fields becomes almost impossible, and the “standard” degrades to simply being a collection of fields with very bland data types, most of which need to be optional. This is hardly the basis for an effective standard.

There are numerous secondary issues – as an example we think that the connectivity piece of the API has the potential to rapidly become a
kitchen-sink api, as it tries to cater for connecting to everywhere
(“FaceBook Connect, OpenID Connect, and OAUTH 2.0”). (…)
This JSR could be reconsidered for submission when some of these issues have been worked out, but at this time it is not suitable for consideration as a standard and should be rejected.

Another interesting comment that worth talking about is Hazelcast:
Hazelcast voted Yes
We also agree with the concerns that others mentioned already however we voted yes because we hope this is going to speed up a bit in the future but maybe it would make sense to try to find another set of spec leads with more time?

As we can see, is quite a general feeling that the future of this JSR is to be closed if another renewal is requested and the problems are not addressed in a positive way.

A little detail for SAP AG that NOT VOTED.

JSR 362 – Portlet Specification 3.0
The EC has approved this ballot with votes:
24 YES, 0 No, 0 Abstain and 1 Not Voted.


The general feeling for this JSR is that, different from other JSRs that were not able to clarify and provide useful explanation, this one after requesting the extension provided good reasons and therefore the EC granted the extension. The only entity to comment was SouJava:

SouJava voted Yes
With several JSRs requesting extensions at this same date, we would like to congratulate the EG here, for being the one to provide a useful explanation for the extension request. Thank you.

A little detail for SAP AG that NOT VOTED.

JSR 354 – Money and Currency API

This final approval ballot is the real deal for JSR 354.
And is now evident after 24 votes YES and 1 Not voted that the EC is quite happy with the work developed and the engagement of the community.

SouJava voted Yes
Very happy to see this JSR come full cycle, with lots of community participation. This is the real spirit of what we want the JCP to be. Congrats!

However IBM and Fujitsu pointed out something important, the license terms:

IBM voted Yes
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.

Fujitsu Limited voted Yes
Fujitsu's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.

A little detail for SAP AG that NOT VOTED.

I would like to congratulate the work that is being carried out on the JCP and the excellent participation of LJC, SouJava, Hazelcast, RedHat and Keil Werner.

I also see that too many entities are voting with no comments, personally I don’t see this with good eyes, I believe this is very bad for the community and the JCP. Things need to be said, concerns need to be expressed. This concerns if not written, can’t be re-called in few years and important facts can be missed.

Bad side also for SAP AG that DID NOT VOTE in any of the Review Ballots.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s