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 JUG site about the adopters of JSRs, so people’s names are on here.
  • We should publish (via e-mail?, via 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.
JSR 350
  • 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

JSR 310

  • 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.

JSR 348

  • 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
  1. Why should we care?
  2. What are the problems?
  3. 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