Skip to main content
Last updated April 23, 2013 18:25, by kittylyst
__TOC__ = Our Voting Record = One of the most important roles that the LJC plays as a member of the JCP Executive Committee is to vote on all of the Java EE and Java SE JSRs as they move through the approval process. This page is an archive of the votes we have made along with the comments that we have supplied along side the vote. We have a few [ guidelines] that cover what we look for when assessing a JSR. = 2012 = == [ JSR 331 - Constraint Programming API ] == '''Vote: Yes''' (Final Ballot) The LJC was originally concerned about the transparency aspects of this JSR. We reached out to the spec lead, and they responded positively and improved the JSRs openness significantly. == [ JSR 359 - SIP Servlet 2.0 ] == '''Vote: Yes''' (Review Ballot) This JSR extends an existing standard which defines an API to deal with processing VOIP based upon the open SIP standard. We concluded this added value to the Java ecosystem, without tying into any particular vendor's VOIP technology. == [ JSR 358 - A major revision of the Java Community Process ] == '''Vote: Yes''' (Review Ballot) "The LJC is looking forward to lowering the barriers to entry for the community at large." This work is underway - basically focusing around Intellectual Property. == [ JSR 357 - Social Media API ] == '''Vote: No''' (Review Ballot) "Whilst the LJC applauds the efforts to build a consensus around the social media space, we feel that this proposal has significant shortcomings and as such, we are unable to support it at this time. The key problem that we see is that the API contains a high degree of domain modelling which is too inflexible to easily accommodate the evolving space. The lack of focus on mobile is also a significant drawback - in 2012, social media is increasingly being driven by mobile applications - it makes no sense to have a social JSR which is not co-ordinated with the ME standards process. The LJC would welcome the withdrawal of this proposal, and its replacement with smaller JSRs which target specific parts of this space instead. " This JSR was rejected and the technical work was refocused into an open source project instead. == [ JSR 356 - Java API for WebSocket ] == '''Vote: Yes''' (Review Ballot) '''Vote: Yes''' (Final Approval Ballot) Our original voting comment: "The WebSockets JSR is seen by the LJC to be of significant interest to the developer community, and we are therefore voting to support the kick-off of this JSR. However, it seems to us that there are significant unresolved issues with regards to the TCK licensing terms, and possible conflict with JSR 348 / JCP 2.8. It is our opinion that these matters must be dealt with by the upcoming JSR to review IP matters within the JCP. If the issues related to this potential conflict are not satisfactorily resolved by the time that JSR 356 comes up for Final Approval Ballot, then the LJC will almost certainly vote NO on approval. We're confident that the possible conflicts here can be resolved, and we have no wish to hold up technical work on standards, but we should also not lose sight of the need to provide a resolution of the conflicts in a timely manner." The LJC raised this issue with Oracle's lawyers, and they confirmed that the fee is only payable by a commercial re-implementation of the standard & does not apply to Open Source or community implementations. We therefore consider this issue resolved & are happy to support JSR 356. == [ JSR 355 - JCP Executive Committee Merge ] == '''Vote: Yes''' (Final Ballot) '''Vote: Yes''' (Review Ballot) The LJC strongly supports the goals of this JSR, but notes that some of the most important aspects of reform are still to be discussed in subsequent JSRs. However, this is a welcome step along the path of reform of the JCP. == [ JSR 354 - Money and Currency API ] == '''Vote: Yes''' (Review Ballot) This is an important JSR to the Java ecosystem, especially the financial services industry. == [ JSR 236 - Concurrency Utilities for Java EE ] == '''Vote: Yes''' (Final Approval Ballot) This is a similar set of utilities to java.util.concurrent but intended for the Java EE space. == [ JSR 338 - JPA 2.1 ] == '''Vote: Yes''' (Final Approval Ballot) The Java Persistence API is the Java API for the management of persistence and object/relational mapping in Java EE and Java SE environments. == [ JSR 339 - JAX-RS 2.0: The Java API for RESTful Web Services ] == '''Vote: Yes''' (Final Approval Ballot) This JSR will develop the next version of JAX-RS, the API for for RESTful (Representational State Transfer) Web Services in the Java Platform. == [ JSR 340 - Java Servlet 3.1 Specification ] == '''Vote: Yes''' (Final Approval Ballot) This JSR is to develop the next version of Java Servlets - Java Servlets 3.1 == [ JSR 341 - Expression Language 3.0 ] == '''Vote: Yes''' (Final Approval Ballot) This is an update to Expression Language 2.2, currently part of JSR 245, JavaServer Page (JSP) 2.2. == [ JSR 342 - Java EE 7 ] == '''Vote: Yes''' (Final Approval Ballot) This JSR will develop Java EE 7, the next version of the Java Platform, Enterprise Edition. == [ JSR 343 - JMS 2.0 ] == '''Vote: Yes''' (Final Approval Ballot) The LJC supports the technical work done in the context of this JSR, but feels that give the innovations that have occurred in the messaging space since the release of JMS 1.1 that this JSR could have been more ambitious and broader in scope. The LJC views the messaging space as one in which further standardisation is possible and desirable, and urges interested JCP members to explore possibilities in this space. == [ JSR 344 - JavaServer Faces 2.2 ] == '''Vote: Yes''' (Final Approval Ballot) == [ JSR 345 - EJB 3.2 ] == '''Vote: Yes''' (Final Approval Ballot) == [ JSR 346 - CDI 1.1 for Java EE ] == '''Vote: Yes''' (Final Approval Ballot) == [ JSR 349 - Bean Validation 1.1 ] == '''Vote: Yes''' (Final Approval Ballot) = 2011 = == [ JSR 321 - Trusted Computing for Java ] == '''Vote: Yes''' (Final Ballot) == [ JSR 352 - Batch Applications for the Java Platform] == '''Vote: No''' (Review Ballot) 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? == [ JSR 348 - Towards a new version of the Java Community Process] == '''Vote: Yes''' (Final Ballot) Whilst there are still a number of important issues to discuss, we view this JSR as a vital first step (but not an end state) in the process of revitalising the community process. == [ JSR 351 - Java Identity API] == '''Vote: No''' (Review Ballot) JSR 351 attempts to standardise a domain model for identity. It is unclear why you would need to standardise the entire domain model, instead of leaving this in the arena of the application programmer. Even if you're in favour of standardising common domain models such as this, 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"). We recommend that this JSR be withdrawn - in its current from we do not consider it fit for purpose, and recommend that these issues are instead explored in an open source project led by interested parties (with full community involvement) which is not considered a standards track project at this time. 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. == [ JSR 336 - Java SE 7 Release Contents] == '''Vote: Yes''' “The LJC votes Yes to the JSR for SE 7 based on its technical merit and our very strong desire to get Java moving again. We note that the archives for some of the Expert Groups that comprise this JSR have not yet been made public, despite a promise from Oracle to do so. We do not feel that this is appropriate for a public and open standards body. In particular, Oracle’s silence as to why the archives have not been made public is harmful to community participation, i.e. the community has no access to historical technical discussions, which are vital for participating in future Java language initiatives. Going forward, we are unlikely to support any JSRs that do not meet minimum standards of transparency.” == [ JSR 334 - Small Enhancements to the Java Programming Langauge] == '''Vote: Yes''' (Final Ballot) == [ JSR 292 - Supporting Dynamically Typed Languages on the Java Platform] == '''Vote: Yes''' (Final Ballot) The LJC recognise the hard work put in to JSR 292 by the EG and wider language community, and thank all contributors for their efforts in this area, which is of keen interest to the community. We look forward to lively discussion and further related enhancements in forthcoming months. == [ JSR 203 - NIO.2 ] == '''Vote: Yes''' (Final Ballot) The LJC thanks the EG, and especially the spec lead, Alan Bateman, for the technical work done on this JSR. == [ JSR 349 - Bean Validation 1.1 ] == '''Vote: Yes''' (Review Ballot)
Please Confirm