First Java Executive Committee ballot for JSR 352 causes confusion
First JCP vote after reform raises future transparency concerns, as only Twitter and London Java Community flag up problems of expert group mailing list.
In the first vote since the Java Committee Process was reformed, creating the JCP Executive Committee, everything appeared to be fairly low key.
The ballot for JSR 352: Batch Applications for the Java Platform was passed overwhelmingly with 12 votes in favour, two no votes and two against, ushering in the javax.batch specification into Java EE/SE platform. But upon closer inspection into the two no votes, questions regarding the transparency of the entire process were created.
The goal of javax.batch is to provide a standardized programming model on Java EE/SE to implement batch applications and an API to submit jobs. The JSR proposal defines the domain area with batch job, step, application, executor, and job manager. But there was contention over the use of a private mailing list within the expert group – completely contravening the JSR 348 pledge to increase the transparency of EG group operations.
The London Java Community, who won an open seat on the Executive Committee and saw that as the highlight of their groundbreaking year, voted No on JSR 352 because of the issues surrounding the use of a private mailing list. They provided their reasoning in the vote comments.
This JSR does not appear to comply with the transparency requirements for JSR 348. It makes mention of EG-confidential business being conducted on a private mailing list, which appears to contravene JSR 348.
Specifically: “The Expert Group will conduct business on a publicly readable alias. A private alias will be used only for EG-confidential information, as needed.” This does not seem to meet the standards of transparency and openness that have been agreed upon. We therefore conclude that we should vote No on JSR 352.
Can the spec lead investigate this and explain what happened here – how this JSR was submitted in this form?
It was revealed later on that this issue was cleared up with them and that the LJC couldn’t change their vote in time. Twitter echoed the LJC’s original concerns
Twitter shares London Java Community’s concerns about the lack of compliance with the JSR-348 transparency requirements. We are happy to support this JSR if it does not sanction the usage of a private mailing list.
Red Hat and IBM’s stances were particularly intriguing, although possibly due to the fact they were part of the initial expert group. Despite saying that they would prefer a model that ‘created an open arena for everyone’, they both voted yes due to the technical merits of the proposal.
Whilst clearly said merits are important when submitting to the JCP, transparency should remain paramount. Many of those voting yes didn’t comment on the apparent lack of openness when it came to the expert group.
The private EG contact over the project was rightly flagged up by the LJC and in turn, the issue was dealt with by the spec lead, yet some bigger companies within the committee didn’t bring up their concerns. Surely this strikes of the rubber stamp process of old and not welcoming in a newer more welcoming JCP? What good is reform if no one takes the new methods seriously?
Sure, there may be some teething problems within the new Executive Committee but it’s not difficult to follow the basic principle of the Java ecosystem of transparency. This scenario have suggested that although we are on the right path towards a more open Java Community Process, there’s still some work to be done before everyone on the elected panel fully embraces it.