BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JCP Members Voting No on JSR-48 WBEM

JCP Members Voting No on JSR-48 WBEM

Bookmarks

JCP Executive Committee member The London Java Community (LJC) announced this week they are supporting an effort to vote down JSR 48 Web-Based Enterprise Management (WBEM) APIs in a move to correct some defects in the specification.

A blog posting from the LJC yesterday said "the No vote is purely a procedural measure. During the discussion of this JSR, it came to light that the current Reference Implementation license conflicts with the terms of the Java Specification Participation Agreement (JSPA) and is therefore not valid. Were the Final Approval Ballot to pass, the resulting standard would be impossible to implement and useless to the community."

According to the blog post, "The LJC, along with IBM, SAP and the JCP PMO, met with the spec leads and resolved the issues around licensing. The executive committee (EC) has agreed that the Final Approval Ballot must fail, and EC members will accordingly vote it down." The gambit will afford the JCP Expert Group some leverage to correct the issues after which a "Final Approval Reconsideration Ballot" can be submitted, effectively providing a second chance. The spec leads agreed and will resubmit the JSR with a modified RI license.

InfoQ caught up with LJC representative Ben Evans to clarify the strategy:

InfoQ: You mentioned that the RI conflicts with the JSPA. What is the conflict?

Ben: The original license did not permit redistribution or derivative works. That's an important restriction when you are building something for inclusion in the Java platform.

InfoQ: How were the issues around licensing resolved?

Ben: The spec leads agreed to change the license terms to comply. The exact means of accomplishing this are still being determined.

InfoQ: The blog posting stated that "some ecosystem questions regarding the health of the ecosystem for this technology, and the number of participants were also addressed." What is that referring to?

Ben: This is a very old JSR, so there was concern about whether there was still a need to complete it. The spec leads were able to point to a large number of companies, and open-source projects - demonstrating that this technology is still in good health.

InfoQ: Can you talk a bit about the JSR, what exactly is this going to add to Java?

Ben: It will introduce additional network management capabilities; WBEM is a standard in roughly the same space as the SNMP network management protocol. It is widely used in operating systems and distributed systems management. The completion of the JSR will simply consolidate the existing picture, and prevent fragmentation / partial compatibility problems - exactly the sort of circumstances for which the JCP is intended to be used.

InfoQ: The blog posting mentioned that there were "a number of minor technical issues discussed". Can you mention what those were?

Ben: Static analysis of the RI was one. Also the need to release the source code of the Technology Compatibility Kit (TCK) so that the intent of tests is clear to implementers, Also, there was some concern to ensure that the implementation of unsigned arithmetic that ships with the RI has been thoroughly tested. Red Hat also raised some concerns in their voting comment about the use of JAAS.

InfoQ: When would the revised spec be submitted?

Ben: After the vote formally fails, the spec leads have 30 days to fix issues & resubmit, so we are not talking about a big delay.

 

Rate this Article

Adoption
Style

BT