London Java Community and Twitter say No to JSR 352

First Java Executive Committee ballot for JSR 352 causes confusion

Chris Mayer
JCP

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.

Author
Comments
comments powered by Disqus