You are currently browsing kittylyst’s articles.
The LJC is voting No on the Final Approval Ballot for JSR 48 (WBEM Services Specification). As this decision may surprise the community, we wanted to ensure that the reasons behind this are fully understood.
The No vote is purely a procedural measure. During the discussion of this JSR, it came to light that the license that the Reference Implementation conflicts with the terms of the 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.
The LJC, along with IBM, SAP and the JCP PMO, met with the Spec Leads and resolved the issues around licensing. The EC has agreed that the Final Approval Ballot must fail, and EC members will accordingly vote it down. The JCP process contains a contingency measure for circumstances like these, known as a Final Approval Reconsideration Ballot.
This Ballot allows the Spec Leads to correct any problems & resolve concerns before resubmitting within 30 days – effectively a second chance. The Spec Leads indicated that they intended to do so, and to resubmit the JSR with a modified RI license.
During the meeting with the Spec Leads, some ecosystem questions regarding the health of the ecosystem for this technology, and the number of participants were also addressed. The Spec Leads were able to point to a wide variety of companies and projects participating, so on this basis, the LJC is happy to support this JSR.
A number of minor technical questions were also discussed – and the Spec Leads agreed to address some of them by releasing the source code for the TCK for this JSR – and to produce a new JSR for a version 2.0 after the initial release to fix any bugs found by the community.
The LJC JCP Committee would like to thank the Spec Leads for making time to meet and address concerns at very short notice, and for their perseverance in completing the JSR process.
As always, if you’re an LJC member and interested in our work in the standards & specification space – please contact one of the committee – we’re very happy to talk about our ongoing projects, and there are always ways to get involved.
Just before Devoxx, the LJC held a Nashorn HackDay in conjunction with Oracle.
With Java 8, however, Nashorn (pronounced NAS-horn, not NASH-horn) replaces Rhino (Nashorn is actually the German word for Rhino) – and Rhino is being removed.
Nashorn is a from-scratch new JS implementation, and designed to take full advantage of all Java 7 & 8 features – including method handles and invokedynamic. It is the first JS implementation to pass the spec tests 100%.
It will ship with Java 8, but it is already & pretty good shape, and with the interest in it, we decided to take it for a spin before Devoxx…
The Hackday took place at Oracle’s Moorgate building – and we were very pleased to have Attila Szegedi, one of the Oracle engineers working on Nashorn as our guide.
Attila opened the day with a presentation about how to use the JS shell (jjs) & how to integrate running Java code from within JS (and how to use Java to call out & run JS scripts from within a Java program).
In the hack sessions, people focused on using Java libraries from Java, comparing JSON processing in JS vs in Java (& some rudimentary benchmarks) with more advanced users looking at trying to defeat the Nashorn security model & sandbox.
It seemed to go very smoothly, and if there’s interest, we’d definitely be keen to run more events focused on Nashorn over the Summer – let us know if this would be interesting (leave a comment below or email us).
It’s New Years Eve, and your JCP Committee is spending a few hours cleaning up a few threads from this year.
We realised that we never blogged to tell you about some new members of the JCP Committee. First of all, we’re very pleased to welcome back Simon Maple. In addition, both Graham Allen and Kim Ross volunteered to help out – so thank you to all of them.
For full details of your committee, please visit: http://java.net/projects/ljc-london-jug/pages/TheLJCJCPCommittee
We’ve also brought up to date our voting record on JSRs to cover all of 2012. You can check it out here: http://java.net/projects/ljc-london-jug/pages/OurVotingRecord
As ever, we’re always happy to talk about our work with the JCP – please come and find us at events if you’re interested – we always want to hear your views and to make sure that we’re representing the LJC to the best of our ability.
Happy New Year and we’re looking forward to more excellent work in 2013.
(Apologies, this has been stuck in draft form for a while, and we missed that it hadn’t actually gone out).
The January 2012 face-to-face meeting of the JCP Executive Committee was held at Oracle’s Redwood Shores campus.
This two day meeting gave the committee a chance to discuss a variety of matters. These included the forthcoming merge-the-ECs JSR (JSR 355) – but we were also able to cover updates to some important forthcoming JSRs – including JSR 335 (Lambdas), JSR 308 (Type Annotations), JSR 353 (JSON API).
The JCP team gave an interesting presentation about statistics related to the JCP sites:
- 65% increase in non-member page views across JCP sites in 2011
- 2/3rds investment in JSRs was made by Oracle (but we need to take into account the cost of platform JSRs, which are disproportionately expensive)
- 32/48 JSRs led by Oracle in 2011 – but is this due to acquisition of active JCP companies by Oracle?
In the roundup of open JSRs, a number of other interesting points came up:
- JMS 2.0 spec lead (Nigel Deakin) wants help from Adopt-A-JSR (Update: We are putting together a group on this)
- Lambda on jdk8 mainline: looking at April for a functional build (Update: This has now landed)
- JSR 353 is very open to additional help – either from Adopt-a-JSR or as additional EG members (Update: Adopt a JSR group has formed)
From the point of view of the LJC’s participation, gratitude and encouragement was expressed from several sides, and I took away a list of takeaways – both action items for us, and ways to improve our process and participation:
- We need to review TCKs and RIs (and licenses) as part of our voting decisions (Update: Implemented)
- The LJC should add an official “check the TCK” step to our criteria (Update: Process updated to include this step)
- I reached out to Brian Goetz to see if there’s anything the community can do to get lambda builds working sooner than that (Update: Henri Gomez was able to release the first OS X build supporting lambdas sooner than Oracle – another point proving the value of community involvement)
- I suggested that Adopt-a-JSR could be expanded to include monitoring participation in JSRs (the number of subscribers to observer aliases, number of messages posted, activity on issue trackers, etc.) – Bruno Souza (from SouJava) may well have some screen-scraping tools that can help here, or we may be able to ask the java.net folks (e.g. Sonya Barry) for an API.
- I made the point that the Adopt-a-JSR groups may well want to help with TCKs but lack guidance. Patrick Curran is going to follow-up and see how we can close this gap.
- I volunteered us to reach out to the Czech user groups to help organize some value-add events for the September 2012 EC meeting in Prague (Update: In Progress)
- I committed us to adding more detail to the Adopt-a-JSR page to give Spec Leads more detail about the programme and to encourage two-way communication between spec leads and Adopt-a-JSR groups (Update: DONE).
The next F2F meeting will be in May – we promise to get the writeup out quicker after that meeting. Please contact myself, or any other member of the LJC JCP Committee if you’d like more detail about any of our work, or if you’d like to get involved – we always have extra tasks for the willing! :-)
JSR 350 is now underway.
This JSR is all about state management. A key example of state management would be the HTTP session state that needs to be managed when building web applications. Java EE obviously has a lot to say about state and state management.
The aim of JSR 350 is to expand and standardize the state management APIs – helping to reduce the need for proprietary vendor APIs, and also to widen the context in which state APIs can be used – for example, in SE applications and contexts.
I’m sure there are people on the LJC who are interested in and have experience with this subject. So this is an open call to get involved. Help to make your platform better – and make sure that this new emerging standard actually meets the needs of the people who use it.
The full description of this JSR is here.
If you’d be interested in adopting this JSR on behalf of the LJC then please get in touch with Ben (@kittylyst) or other members of the LJC JCP committee.
If you have a decent amount of experience in this area and think you might want to join the Expert Group for this JSR, then contact Ben and he can talk with you about what that would entail and help you through the process if need be.
Attendees: Ben Evans, Martijn Verburg, James Gough, Richard Warburton, Mike Barker, Trisha Gee
- JCP rep in Red Hat has changed, and Red Hat should be more engaged now
- OSCON was awesome – hopefully it will prove to be a catalyst for improving relationships between various parties involved in the JCP.
General JSR points / Comms:
- We need to communicate / explain the benefits of being on an Expert Group to our membership
- When a person “adopts” a JSR, they should become the LJC official “ambassador” for that JSR.
- Add page to LJC java.net JUG site about the adopters of JSRs, so people’s names are on here.
- We should publish (via e-mail?, via java.net LJC JUG Wiki?) digested, developer-friendly versions of the JSRs, since the language can be a little impenetrable sometimes. Going forward, ideally the person who adopts the JSR would do this, but probably for the near future people might be less likely to adopt unless they can read a friendly summary of what it is.
- Container managed state – e.g. session state
- Patrick Curran is sorting out some minor procedural issues around the license
- It currently has an Expert Group which is still in formation – made up largely of vendors
- We should encourage adoption from the LJC, to get real end users on the board. This is an area where our membership can add value.
- Ben to explain current situation and canvas for possible EG members
- New Date & Time
- Is a good example of “adopt a JSR”
- James is trying to take some ownership of the TCK for this JSR, and will mail the group in the near future and inquire for some feedback
- Unit-style tests exist, but the TCK needs to be more acceptance-style tests. There may be some re-use
- We should evangelise this project to LJC to get help. Could be a good entry point for people who want to get involved in open source etc
- When we’ve got more information on what’s involved in building a TCK, and some good practice, we should document it somewhere (e.g. a wiki, the JUG page) so that other people can learn from the experience and add to it.
- Changing the JSR process itself
- This is a good area for more involvement, so we need to spark interest/conversation. Mike to take point – to explain
- Why should we care?
- What are the problems?
- Why is it trying to solve these things?
- Raise the issue of language? – it’s difficult to get involved in the process when the language of the JSRs can be dry and un-engaging. Program to write easy to understand summaries of JSRs should help
- Clear consensus among the committee for a Yes vote and continued effort / participation in the EG
It may comes as a bit of a surprise given all of the publicity around Java 7, but the final version of Java 7 still hasn’t been approved yet.
Java 7 actually comprises 4 separate JSRs – 1 master JSR and 3 specific ones. They are all up for their Final Approval Ballot, which is due by the 18th July.
JSR 203 NIO.2 – New I/O v2
JSR 292 Supporting Dynamically Typed Languages on the Java Platform
JSR 334 Small Enhancements to the Java Programming Language
and the big one:
JSR 336 Java SE 7 Release Contents
The reason behind the strange-seeming delay in final ratification is that Java is a bit different to other popular programming communities. For example, the .NET community is run by just 1 company – Microsoft – and the development community and other corporate partners have no formal say in how the community is run. If MSFT decides to change the entire development landscape with their next release, then they can. There was all sorts of gnashing of teeth in the developer community when Silverlight was effectively demoted as part of MSFT’s new roadmap.
On the other hand, in some of the open source communities, such as Python or Perl or Ruby, things can be a bit more badly defined. Some communities are more formal than others, but in many cases there is a small group of community members who contribute “most” (in some loosely defined sense) who are responsible for driving change forward in releases. If corporations are contributing a lot to a particular community, then their representatives in the community will generally be well regarded and listened to.
In good open-source communities, this tends to lead to releases which reflect the overall consensus view of the community. However, large communities are not monolithic, and it’s important to remember that you can’t please all of the people all of the time.
The Java world is a little different. Java was always intended to represent a concert of interests – originally very corporate focused, but bringing in prominent individuals and communities as the Java ecosystem has grown. At the heart of this is the Java Community Process (JCP), which is presided over by the Executive Committees (there’s one for SE/EE and one for ME). It is this Executive Committee that the LJC was recently elected to.
The ECs are responsible for approving every official Java standard (which are all expressed as JSRs). This happens by a vote. This a simple process – Yes, Yes with comments, Abstain, No and Fail To Vote are the options, and the results are binding – if 50% or more vote Yes, the JSR passes and becomes an official standard.
This process means that the final votes have to be scheduled against a moving target. The final version of the language specification, and the reference implementation (which for Java SE is OpenJDK) are formal documents. So it isn’t really possible to have a final vote on them until the release is basically ready – because otherwise EC members can’t be certain what they’re voting on.
The final vote being so close to the release date is an artifact of the JCP being a mostly open standards process.
The reason that it can be described as “mostly open” is because it has been, at times, a little bureaucratic. It was born in an era when corporate interests were the only type that were really considered. Open source hadn’t taken off yet. The strong, vibrant technical communities we see didn’t really exist. Even the Internet wasn’t anything like today’s version.
Part of the work that the LJC are currently engaged in on the Executive Committee is a reform of the JCP, to make it faster, more streamlined, and fundamentally more transparent and easier for the ordinary developer to participate in. There’s a new JSR – JSR 348 – which is a first step to reforming the JCP. There will be at least 2 or 3 more needed to get the process fully reformed, but we feel that taking some small, (hopefully) easy steps first is the right way to get some momentum going.
Finally, if you’re interested in the JCP, or in standards work, or in the future direction of the platform – please get in touch. The JCP group within the LJC is always looking for people who are interested, in the views of our members and in the overall thoughts and direction of our community. We try to spend as much time as we can canvassing your opinions, but if you have strong feelings about anything – then let us know. Start a thread on the mailing list, or come and talk to us if you’d rather talk privately. We’re always happy to hear from you, and by doing so, we can ensure that we’re representing you as well as we can.
Attendees: Trisha Gee; Mike Barker; Barry Cranford; Martijn Verburg; Ben Evans; Simon Maple
As an overall note, we don’t assign action points to specific people in the meeting other than those whose names are mentioned above. Rather than swamp ourselves with process, we’re feeling our way around to see what’s going to work best for us as a grassroots user organisation.
- We agreed that Barry would hold the physical paperwork at his company offices. This resolves point 11 of the last meeting.
- We agreed unanimously that James Gough would be added to the LJC/JCP committee.
- Patrick Curran, the chair of the JCP, will be visiting London on July 9th. We resolved to hold a social at Vinopolis, open to all LJC members, to meet Patrick. Trish to organize.
- Ben to blog about the inactive JSRs to see if any LJC members are interested in helping to get them going again – the start of an “adopt a JSR” program.
- Ben to post to list about bean validation 1.1 JSR and see if any LJC members would be a good for for the EG that Emmanuel Bernard (Red Hat) is putting together.
- We agreed unanimously that Trish should act as tertiary for the JCP Committee, and attend EC (and JSR 348 – JCP.next) meetings in the event than neither Ben nor Martijn is available.
- We discussed the possibility of setting up a “community interest” JCP mailing list for JUG leaders – to try to reduce the possibility of swamping the current jug-leaders mailing list. It was felt that this was worth discussing further with Bruno Souza (SouJava) and other community EC members.
- We discussed which forthcoming standards the LJC may be able to contribute to technically (ie areas where we have members who could make a good contribution). The initial list of obvious areas is: Bean Validation, Modularity / Jigsaw, Lambda, JMS 2.0, Coin 8 and MLVM. Further discussion is needed to see how we can best help our members to get involved.
- It was noted that we need to tag JCP-related posts on the blog as a way of keeping track of our involvement in the JCP and open work threads – this will also provide a useful public record of our contribution.
- Ben to organize the next Committee Meeting in mid-July.
LJC members – this is a unique opportunity for you to get involved in helping guide the future of the Java ecosystem! Please contact me (Ben Evans – @kittylyst on twitter, or through my profile on the LJC meetup.com site) and let’s talk!
Attendees: Trisha Gee; Mike Barker; Barry Cranford; Martijn Verburg; Ben Evans; Simon Maple
As an overall note, we didn’t assign action points to specific people in the meeting other than those whose names are mentioned above. Rather than swamp ourselves with process, at the moment we’re feeling our way around to see what’s going to work best for us as a grassroots user organisation.
- The LJC will spin off a small group to handle JCP-related matters, so that we can keep it manageable but encourage a more active participation from members (i.e. more active than the associates group). This group will start off being those who attended this meeting, and will grow to include additional LJC members who have the time and interest to participate regularly.
- Members of the LJC JCP group are expected to turn up to all f2f meetings, and to be active and vocal participants of the group. This does represent a certain level of time commitment.
- Separate mailing list for LJC/JCP committee to be created (done!)
- We’ll send minutes of the JCP meetings to the new google group for the JCP committee. A public summary will go into a monthly update blogpost (see next point)
- We (the LJC/JCP committee) will write blog posts about important events / topics related to what’s been going on in our JCP world. The blog posts will be pointed to via the usual channels (LJC mailing list, twitter etc). We will also point the other Euro JUGs to these updates. At minimum, the summary of minutes will be posted – but there will be additional posts on topics of interest.
- If there’s an upcoming important topic to vote on, we will do lightning talks on the subjects at a suitable event so that we can inform the community about the issue and request feedback. Lightning talks will be delivered by a member of the JCP group.
- We will compile a list of open JSRs and encourage involvement from the LJC. We should encourage people to “Adopt a JSR” – find out about it, present about it, get involved. We should blog to suggest this, and we need to find ways to create a low barrier to entry for getting involved.
- Suggestion to do a session at the unconference on the JCP and our involvement
- Trish to prepare a lightning talk on the JCP and JSRs
- Mike to present a lightning talk on Project Coin
- ISSUE: If we have any physical paperwork from our involvement, where do we store it? Tabled for discussion at next meeting
LJC members – this is a rare chance for you to get involved in helping guide the future of the Java ecosystem! Please contact me (Ben Evans – @kittylyst on twitter, or through my profile on the LJC meetup.com site) and I’ll get you started!
As you hopefully already know, in May of this year, the LJC was voted onto the Executive Committee for Java SE / EE.
There’s a blog post about it here: http://londonjavacommunity.wordpress.com/2011/05/27/the-jcp-reform-and-what-it-means-for-the-java-developer/ if you missed the announcement and would like to find out more about what all of this means.
One of the first activities we’ve been involved in is the final vote to approve Java SE 7 as a standard. Based on the overall feeling of our membership, we voted “Yes” with this comment:
“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.”
We feel that the cause of advancing Java is too important to hold up – and the JCP doesn’t really provide us with a mechanism for delaying a vote.