You are currently browsing the monthly archive for September 2011.


  • Simon Maple
  • Richard Warburton
  • Somay Nakhal
  • Ben Evans
  • James Gough
  • Martijn Verburg
  • Trish Gee
  • Mike Barker

(Tasks in Bold)

General Minutes 
  • Welcome Somay Nakhal to the Committee!
  • We need to start having formal agendas before each meeting (MV to create next one)
  • We’d like to have a venue with free WiFi for all  (TG to investigate possibilities)
Update from Face to Face (F2F) EC meeting from BE
  • Hosted at Goldman Sachs in Jersey City, USA
  • Good to put names to faces, made following JSR-348 WG meeting run more easily
  • LJC ‘Adopt a JSR’ program was well received
  • Lots of support for JSR-310
  • JSR-348
    • Main issue was about ballot stuffing.  The PMO will investigate and act appropriately if there is evidence of suspicious voting.
    • SE and ME committees will merge (partly as ME committee rarely makes quorum).
    • 24 seats + chair is the new target, down from 32 today, ‘extra’ seats will die a natural death.
  • Java ME
    • Hardware baseline – so price point drops over time?  In our opinion this does not match what the industry is doing.
    • Code line is currently based off 1.4.2, they’re proposing to do an ME7, base lined against SE 7 but with some features (like invokedynamic) will be removed.
    • ME seems to be heading towards the embedded space.
    • ME for SE developers LJC session by Oracle to help us gain insight into this area of standards (MV to organise).
  • ‘Adopt a JSR program’ is vital. We shall proceed by:
    • Update with our JCP status (MB to follow up)
      • Blog about JSPA signature (BE to post)
    • Producing a Glossary of Terms (TG to update wiki)
    • Push out the ‘Adopt a JSR Program’ post (RW)
      • Give Richard access to LJC blog (MV)
      • Forward post to JUG leaders list during JavaOne once done (MV)
    • Send out details of our page to committee  (MV)
    • At the next JCP meeting, review our JCP/JSR Content on (all of us)
    • Adopt a JSR Logo – CC licensed Duke needs you (MV)
JSR-310 update (JG)
  • Blog post on TCKs etc (JG)
  • Volunteer Cat herding (JG)
  • Next step is to start the TCK planning stage (JG)
  • Contact threeten mailing list (JG)
  • Workshop on TCK at Open Conference (JG)
  • Get Oracle involved – Roger Riggs – (BE)
JSR-349 (Bean Validation)
  • Looking for adoptees, get Spec lead to send out a description (MV)

JSR-350 (session state enhancement)

  • Adopt a JSR – Introduce Madhu Konda and SN (BE)
  • Investigation, talk to Jeff Trent (and his upcoming replacement) (SN)

JSR-351  – Identity Management

  • Contact spec lead for further clarification of JSR  (BE)

As part of the London Java Community’s Adopt a JSR program, I took on the role of increasing awareness on JSR-310. JSR-310 is the proposed solution for improving the current data and time system within Java. For more information on JSR-310 please view this previous blog post. Following introducing JSR-310 to the London Java Community I have also become involved in planning a potential TCK (Technology Compatibility Kit) for JSR-310. When I first began the task I asked myself a few questions, which I will aim to answer in this blog post. The format of the post will be in questions and answer, so the reader can quickly skip through the topics they are not interested in. There will also be some more extended points within the post on the work we are currently undertaking as part of the London Java Community to contribute to the TCK for JSR-310.

Why should general Java developers care about JSR-310 and the TCK?

Most developers have used the current date APIs that are available in Java. They’re difficult to use, often lead to unexpected results and have a general confusion about them. JSR-310 aims to address these problems and ensure a better system for the future of Java. If contributions are not made by the community and Java developers this important JSR will miss the deadline for Java 8. My aim is to help get this through to Java 8 and I’m looking for as many people in the community to enable us to get there. Please feel free to contact me for more information:

What is a TCK? What are the terms that surround the JCP on this topic?

Before you can appreciate the reason for a TCK the first step is understanding the separation of concerns between the JSR (Java Specification Request) and the RI (Reference Implementation). The JSR has the purpose of stipulating the exact requirements of an implementation and is effectively the basis for the JavaDoc style interfaces, rather than getting bogged down in the implementation details. The reference implementation’s job is to be the code that fulfills the requirements, it should do no more and no less than what is required from the specification. The job of the TCK is to mediate the specification against the actual implementations, keeping in mind that there might be more that one implementation for a specific JSR.

What’s the difference between unit testing and TCK testing? What do both address? Is there any overlap?

The purpose of a TCK is to test the “conformance” of an implementation against a JSR, but it’s more than just that. It is a suite of tools, a test framework and documentation to allow someone to take the JSR and understand how the implementation must behave to pass the kit. Unit tests are internal to the reference implementation and are not necessarily going to provide the full suite and documented nature of a TCK. Is there opportunity for reuse, definitely! However the unit tests that might be reused from an existing implementation need to be selected with care. The tests should only be testing the specification rather than any specific functionality that could be internal to an implementation. In the example of ThreeTen the strategy will be to view the JSR Early Draft Review independently from the code base that already exists to ensure a high quality TCK is created.

What makes up a TCK?

As mentioned the TCK is suite of tools to allow an implementer to create a successful reference implementation. It also requires careful planning, this is the phase we are landing in now for JSR-310. We will be looking over the coming weeks to produce the following plans; project, test, integration, documentation and QA plans. The previous sentence is quite work heavy to look at on first glance and immediately it’s clear to see that the TCK is a project and application in itself.

The TCK needs to have the concept of conformance rules. These rules will measure the success of whether the implementation conforms to the specification. The test suite is a collection of conformance tests. The TCK should also allow the identification of methods that might be outside of the JSR, additional methods should cause the test to fail with a detailed description of the failure.

Because this is a piece of software what will be used by other developers, the error messages that are generated from the TCK need to be logical and clear as to why that test failed. Reporting and good user feedback is part of this framework.

Following the completion of a JSR the TCK doesn’t end, it should enter a maintenance phase. It is possible that over time errors will be spotted in the TCK and this needs to managed over time.

What resources are required to build a TCK?

People! People from the community and experts from the Java ecosystem. However, before this can be done we need to ensure that the planning phase is well underway before the actual development can take place. For people interested in ThreeTen and JSR-310 please familiarise yourself with the following documents and websites:

How long is it going to take?

It depends on the number of test cases that are identified, this will be part of the planning phase. A potential formula directly from the How to build a TCK document:

(A-Num × CovBreadth ÷ DevRate) × NumEng = Test Development Time (in weeks)


  • A-Num is the number of testable assertions defined by the specification. 
  • CovBreadth is the coverage breadth goal. For example, 0.75 for 75% breadth coverage.
  • (Note that the ideal practice is to thoroughly test all elements which requires 100% breadth and depth coverage. Assertion breadth coverage of only 75% means that assertion testing is incomplete.)
  • DevRate is the test development rate. According to Sun’s experience a typical test development rate is approximately 12.5 test cases per week for a test developer to write, document, and debug assertion test cases (including simple test framework development).
  • NumEng is the number of engineers writing tests.

I will use the above to estimate a back of the envelope time frame for the TCK and the preparation.

How can you get involved?

We are looking for volunteers to help us build the TCK implementation and that effort will be increasing over the next few weeks. If you are interested or would like to know any more information please drop me an E-Mail. There are many levels at which you can be involved with a project like this, it might be that you’d like to write some technical documentation, or actually get stuck into the code. Whatever challenge you are looking for, we look forward to having you on board.

At the LJC we’re trying to democratize the future development of the Java platform. The development of Java is run through the Java Community Process – which splits up changes to the platform into Java Specification Requests (JSRs). A JSR is a specification for a set of related changes to Java, and there are a lot of them. As an organisation that is trying to bring the wider developer community into the standards process in order to inform the decsion making process, improve the standard and innovate the platform we’re promoting the ‘Adopt a JSR’ program.

The idea behind Adopt a JSR is that you, a Java ecosystem enthusiast, can contribute to a JSR by following its progress, helping out on an expert group or informing the wider community of its progress and evangelising its benefits. You can take your industrial expertise and help progress Java in a direction that benefits you and the wider community. The LJC are a voting member on the JCP and can help facilitate any ideas or suggestions that you may have on the matter, so if you want to know more about how to get involved, please contact the LJC’s JCP Committee.

At present there are several JSRs that we’re seeking participation for.

  • Date and Time (JSR 310)  – the upcoming improvements to the Date and Time Api are requiring a TCK. James Gough (@goughjam) is helping coordinate the LJC’s effots here.
  • Java Message Service 2.0 (JSR 343) – the next version of the important JMS standard is currently being developed. The LJC is in contact with Tim Fox and Colin Crist, who are working on this project.
  • Bean Validation 1.1 (JSR 349) – a new maintenance release for Bean Validation. Do you use Bean Validation and want to help improve it?
  • Session State Management (JSR 350) – introduces an API that will offer a modular system for dealing with State management, generalising some of the ideas from the HttpSession State object. Somay Nakhal is interested in helping out with this proposal.

Of course if you want to work on something else, or even propose a new JSR yourself, then don’t hesistate to contact us. We’ll also be documeting our progress on our wiki.

Perhaps you’re tired of some problem within Java that you’re always encountering. Perhaps you’re trying to give back to a community that has helped you grow as a developer. Perhaps you just want to contribute in a meaningful way to an important and influential platform. Whatever your motives, its time to contribute because Java needs you.

Up coming conferences
The autumn conference season is upon us and I have written a quick overview of the most notable events.  If you have never been to a conference before it can seem quite expensive, however it is cheaper than a training course and in terms of what it can do for your motivation and career development, the right conference is a very worthy investment in yourself.

Community events
After the summer  holiday, the number of community events is increasing again.  Here are some things to watch out for

Tonight the London Clojurians are have their monthly dojo at the Thoughtworks offices in High Holborn and its a great way to get a quick shot of functional programming experience in a very friendly and enthusiastic environment. Free sign up.

On Wednesday night the London Software Craftsmanship group are having a group code review.  This is a great way to experience different coding styles, get feedback on your code should you submit some and practise reviewing code so it becomes a natural and flowing task.

Monday 3rd October the London Clojurians have an intriguing “performance” on using Overtone, a Clojure front-end to the state-of-the-art realtime sound synthesis engine SuperCollider.  There will be sounds galore as the live coding session steps you through the architecture and some of the deeper computational questions that working in a musical context forces you to answer.  It sounds a blast, so sign up for free.

Not to be outdone by the Clojure community, there is a Scala Lift-off 2 day conference at SkillsMatter on the 13th-14th October.  If you want to practice your Scala with others, then TIMGroup (YouDevise) are hosting the London Scala user groups monthly dojo, this month on the 20th October.

For something lean and agile, Kevin Ryan is a great speaker on all things kanban and system thinking, drawing from many years experience working with teams and helping them become more effective.  Get your flow going and sign up to his talk on the 6th October.

New > UK Atlassian community
If you use JIRA, Greenhopper, Confluence or the development tools from Atlassian, there is an opportunity for you to get involved in this new community.  On 26th October they have the first event, a launch party and community kick-off, sponsored by Atlassian so there will be some swag on offer.  If you are interested, please join the UK Atlassian community and make your voice heard (or listen out for how you can bag some swag).

There are lots more events coming up so there are plenty of opportunities to learn and get involved with the community – making new friends and finding new opportunities.

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

Hi All, (this post is x-posted from Martijn’s personal blog and the java7developer blog)

Recently I’ve received a bunch of private correspondence from people confused/worried over the change in the default Java packaging for Linux. For many Linux distributions, the official Sun/Oracle version of Java has been packaged up as the default Java for the platform. However, due to a recent licensing change, this will no longer be the case! So, is this a positive or a negative thing for the Java and open source ecosystem? Read on for my take on it 🙂 


Dalibor Topic announced that With Java SE 7 and JDK 7 being released, and with OpenJDK as the official Java SE 7 reference implementation, that it was finally time to retire the non open source “Operating System Distributor License for Java” (DLJ).

What does it mean for me?

The knock on effect of this is that Linux distributions will on longer package Oracle’s Java (== OpenJDK wrapped up in some proprietary bits and pieces) as the default Java. This can/will cause problems for some Java users initially as there are a smattering of bugs (especially in the Swing UI libs) still left in the OpenJDK that affect programs like PCGen. However, some Linux distributions had already taken this path some years ago, most notably Ubuntu and the last remaining bugs are being cleaned up pretty quickly.

Positive or Negative?

Overall, I think this is a positive step in the right direction for free and open Java on Linux platforms. This sentiment was welcomed by well known open source advocate Simon Phipps in a twitter post. The fact the the OpenJDK is now the reference implementation (combined with efforts to open up the issue tracker for the OpenJDK) means that means that a vast host of Java/Linux end users can now directly improve ‘official Java’ for all of us.

I want the Oracle version!
Linux users who need to use the proprietary parts of the Oracle JDK 6 or Oracle JDK 7 binaries can of course as usual simply get the gratis download at under the same terms as users on other platforms. However, if it is due to a ‘bug’ that is discovered I strongly encourage those users to submit a bug report to the OpenJDK project, so that any issues can be fixed for all of us.

Opinions and further comment is welcome!

What is the LJC

The London Java Community (LJC) is a group of Java Enthusiasts who are interested in benefiting from shared knowledge in the industry. Through our forum and regular meetings you can keep in touch with the latest industry developments, learn new Java (& other JVM) technologies, meet other developers, discuss technical/non technical issues and network further throughout the Java Community.