Over the last year the LJC has been involved in JSR 348 – a JSR reforming the JCP itself, and is also becoming involved in its successor – JSR 355. Despite the benefits that JSR 348 presents, due its complex and technical matter it is quite hard to read the specification itself – so here’s my layman’s take on the key developments in this space.

Transparency – a key improvement put forward within JSR 348 is improving the transparency of JSR development. In practice this means that Expert Group business is to be carried out on public mailing lists, requiring issues and comments to be tracked through a publicly viewable issue-tracking mechanism, and requiring EGs to respond publicly to all comments. It also requires that Spec Leads disclose their licensing terms and terms of use in advance and requires them to be compatible with the JSPA.

Maintenance – some JSRs have become inactive or are moving very slowly. JSR 348 introduces timeouts for these processes so that JSRs that aren’t functioning properly can be clearly identified and either their problems resolved or the JSR closed.

Ambiguities – this JSR also removes some technical ambiguities, for example the legal review of proposed licensing terms and makes guidelines within the old private EC Members Guide into a publicly readable EC Standing Rules document.

Governance – At present the Executive Committee of the JCP is split into two groups – the SE/EE committee that the LJC is part of and the ME Committee. JSR 355 will follow on from these reforms by merging the two committees into one committee, and reducing the overall number of elected seats.

The combination of these changes will make the JCP leaner and more reactive, as well as continuing to lower the barriers for day to day developers to get directly involved with the language and platform that they love!