Today 11 May 2015 is a big day for several JSRs. Several companies and JUGs that compose the Executive Committee for SE/EE will be voting for the bellow JSRs to continue or to park their activities.
JSR 350 – Java State Management
JSR 351 – Java Identity API
JSR 362 – Portlet Specification 3.0
JSR 354 – Money and Currency API
I will be giving a very fast and as clear as possible, review about each of this important JSRs.
This review is intended to be giving just a quick overview of each spec, and should not be considered as a SouJava view of the facts in any manner.
1) JSR 350 – Java State Management – JSR Renewal Ballot
This spec was approved with commentaries 2 years ago.
I collected some of this votes and respective comments in order to be easier for you to understand the problems and possible solutions that this JSR is going to have to face:
London Java Community – Vote: YES
“We echo some of Red Hat’s and Software AG’s concerns. There are some implementations of this idea in Tomcat, JBoss and Weblogic, but they need further fleshing out in the marketplace. That said we’d like to give the EG further opportunity to build out a prototype RI and explore this space in full.”
SouJava – Vote: YES
“SouJava is not satisfied with the reasons expressed for the requested extension, and we would like to see what the SpecLead is doing or plans to do to revert the lack of participation in this JSR. But, since the SpecLead states that the EG has made good progress recently, we are willing to give a vote of confidence. We expect the EG to address the issues raised by other EC members if they want to move this JSR forward.”
IBM – Vote: 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.”
Software AG – Vote: NO
“JSR350 as currently proposed seems to offer little over a data grid standard..
The is discussed in this recent powerpoint (https://java.net/projects/java-state-managemen/downloads/download/JSR%20350%20State%20Management_v3.pptx) JSR350
Consistent with the no vote for JSR347, I think a multitude of overlapping standards will not serve the interests of the Java community.”
RedHat – Vote: NO
“Due to the evolution of the space, and the direction the specification has taken as the idea has matured, we think standardizing such concept is premature. We encourage the expert group to start an open source project to gauge the community interest of such abstract and contract driven API in the persistence space.”
In total, 22 Votes YES and 2 Votes No.
I have been digging into the issue tracker and email list for this spec, and I was not able to find anything that could assign and give right priority for the problems related above.
I’m going to leave the links here so you can check for yourself.
It seems so far that after the transition from the previous spec lead to the actual lead (Tim Watson – Oracle), something is not very clear in relation to what they did to address the problems reported by the Executive Committee.
Unfortunately the lack of information provided, from what I see is going to be very hard to address this problems, and is unclear whether if this problems have or not have been addressed correctly.
2) JSR 351 – Java Identity API – JSR Renewal Ballot
This spec is related to authentication protocols for users and respective sessions. (eg: CAS).
I did a little resume for this spec, and this are one of the possible scenarios that this spec will be useful for, but is not in any form covering all the possible manners this spec could be used:
1) Classic Use Case, Client -> Server. Where the client submits a search for lets say a collection of items. The client should then send to the server his credentials that may grant him access to the collection. The server then receive the credentials, and authorize or not the client to have access to the items collection.
2) A server that answer to multiple clients, this server is responsible to take care that none of the items that are shared to the user A, is shared to the user B if the rule does not allow this sharing. This permissions have to be extended to the basic operations that can be classified as eg: Create/Update/Delete, et. Very similar to what you will see if using CAS auth inside the Spring Framework.
From what I was able to dig in, this spec is quite clear, it have many other examples where this security protocols can be applied.
I believe also that Oracle is very interested in continue and push this work forward. From my point of view, this spec is not going to be parked.
3) JSR 362 – Portlet Specification 3.0 – JSR Renewal Ballot
For this spec, before we start to analyse what are the internals of it, I would like to point to the default comments for the problems this spec have related to its licensing model.
Its nothing to fear of, but is something that the community have to keep the eyes on and follow up on the progress.
“On 2014-02-09 Fujitsu Limited voted Yes with the following comment:
Fujitsu’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms.”
“On 2014-01-30 RedHat voted Yes with the following comment:
Red Hat’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms. Red Hat would prefer a licensing model that creates an open arena for everyone, including those not members of the JCP and removes any ability for one individual or vendor to exert undue control over a standard. We are an open source company and hence would like to see such a licensing model for JCP contributions. Note however, that this comment is not necessarily directed at the license terms for this JSR, but is a statement of Red Hat’s preferred licensing model.”
I believe this spec is very important for the Java ecosystem, and even tho, there are some little problems with the licensing model, there is not much to fear and I believe this spec is not going to be parked.
4) JSR 354 – Money and Currency API – Final Approval Ballot
This spec is really really important, I would say that is the most important spec that is under review. This spec promises to solve many problems that Java developers (like you and me) have to face on the day to day basis if you work with Java, developing apps for eCommerce, banking, financing, insurance, etc.
The authors of the JSR 354 are alerting for the fact (that we all know from long time) that the JDK does not have much APIs that can address currency operations. There is very little method that can be used for this matter on java.util.Currency but unfortunately this can only be applied for ISO-4271.
Again, the authors of this spec are alerting for the fact that JDK does not support arithmetic calculus or money conversion algorithms.
This spec, however intend to be implemented as a standalone app, and could be implemented completely on the JDK, however this integration may affect the usability of the java.math and java.text. This JSR was drastically reduced and great part of its scope was already implemented and open-sourced as Apache License on the JavaMoney lib. http://javamoney.github.io/
The authors of the JSR 354 are very keen to implement this new functionality’s on JDK9, however there is already a work in progress to adapt this spec to the JDK7 and JDK8. We can see why, there are many many banks and finance institutions that may take several years to migrate to JDK9.
Some of the Use Cases that can be considered, and where the JSR-354 could be applied:
A) International E-Commerce website, where the customer could buy items taking into consideration its locality and its proffered currency.
For example: A customer is buying 1.5KG of some beauty products. In this case as the number is not integral, the weight have to be multiplied by the preferred currency and the price must be given to the client. This is such a simple operation, but believe me, without this JSR, to program a simple use case like this can take quite of a time.
B) Trading: Stock exchange apps need to be very fast giving prices. A Price can change in less than 100ms. Imagine you are working in a Trading system and you may need to do the following: Given a local currency, add a % of a total value of a action taking into consideration a dynamic multiplier (example: how much money each operator may want to win). Imagine you need to do all this, in less than 2ms. Just for a moment, imagine how complex this could be to develop without JSR-354. :O
C) Virtual games and Gaming portals: Facebook for example have many games where people play with fake money. This users can then buy extra items and sell extra items to other players. Some of this extra items if not all, are priced with real money. Each user lives a different country, using a different currency. Oh, this without say that they may choose to use for example Bitcoin?
This scenarios can be extended to a vast number of applications like: Social markets, banking e insurance, etc.
All this apps may face the same sort of problem, a Java dev must be able to convert several different currencies, multiply it using many dynamic multipliers and algorithms that calculates the profits for each of the involved parts. This must be FAST, must support historic changes, must be easy and fast to be implemented.
This spec is, as you could see already, very very important for the Java ecosystem as a whole, may devs like me may have faced this challenges and may have built “home-made” solutions to solve all this problems. Well it seems that JSR-354 is going to be a life saver for lots of people! I belive this spec will be renewed, the documentation is quite clear and the roadmap as well.
I hope you have learned a bit more of each one of this specs, oh and I will be posting the results for this ballot review as soon as they are released!! o/