Here is the reasoning behind our recent votes.
Please refer to our detailed explanation of each criteria –>
JSR-321 – Trusted Computing
Why we’re voting yes for Trusted Computing (JSR-321)
JSR-321 is fairly transparent (open wiki, good documentation, RI and
TCK available) but lacks in some areas (no observers alias mailing
list, no public issue tracking). This JSR is run under JCP 2.7 and it
is not obliged to meet the transparency goals of JSR-348. However, we
feel that a good JSR should run an open observers mailing list (i.e. a
read only copy of the EG mailing list) so that potential participants
can see why technical decisions were made. Likewise, a public issue
tracker (such as JIRA provided by java.net) would go a long way
towards gathering feedback for this JSR.
User & Vendor Participation
question the slight lack of vendor participation. This could hinder
the adoption of the JSR. Open Source RI and TCKThe LJC fully supports the decision for the RI and TCK to be under the
GPLv2 with ClassPath Exception license. Open RI’s and TCK’s are
important! Does it Work Well as a SpecificationThe LJC does not have direct expertise in this area but does note that
this is effectively a re-implementation of the Trusted Software Stack
in the C standards space. This stack is used fairly widely and so it
indicates that there is a need for a Java compliant standard in the
same space. There are not a lot of competing Java implementations, but
the EG has based the RI off the lessons learned from the C standard
and we think this is a good thing. General Merit
This JSR has reasonable merit and has clearly had a lot of time,
thought and effort put into it by the EG.
JSR-352 – Batch Processing
We voted “No” because at the time we cast the vote, JSR-352 had not met all of the openness and transparency requirements of JSR-348. Those issue have since been corrected and despite our “No” vote we made at the time it would today be a “Yes” vote.
For the curious, JSR-352 had made mention of EG-confidential business being conducted on a private mailing list, which would have contravened 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.”
The LJC would like to thank the EG of JSR-352 for resolving this matter quickly, and wishes it had been possible to change our vote in time.
If you feel that there are other criteria that should be applied by
the LJC JCP Committee when assessing JSRs, then feel free to contact
us. Either on the LJC mailing list or directly, we tend to be at a
lot of the meetups if you want to chat face to face.
Martijn (on behalf of the LJC JCP Committee)