You are currently browsing the category archive for the ‘Adopt a JSR’ category.

What’s Jakarta EE?

Over on Jakarta EE you’ll see our new LJC logo as a Participant member.  This blog post details what Jakarta EE is and what the LJC hopes to achieve within its community!

Jakarta EE is the new brand name for Java EE. For those who missed it, the Java EE platform was recently donated to the Eclipse Foundation (as Eclipse EE4J), the FAQ gives the background to this.

The existing Java EE 8 platform is being migrated to the Eclipse Foundation.  There’s a lot of new build farm activity taking place and the end goals for 2018 are:

  • Q3 2018 – Release Java EE 8.0 by the Eclipse Foundation.
  • Q4 2018 – Release Jakarta EE 8.0 projects (which will be identical code wise to Java EE 8.0) by the Eclipse Foundation.

Both of these releases will be certified against the appropriate TCKs (which are also being open sourced and donated to Eclipse).

In parallel the community at large is looking to the future of Java for enterprise developers.  A future which is lightweight, fast, cloud native and micro services based.  This work has already started and vibrant discussions (for example, around the role of the Servlet container and what types of profiles make sense in a modern world) are taking place on several mailing lists. We highly recommend you sign up to the lists and join in!

LJC’s role in Jakarta EE

The LJC currently holds technical, legal/oversight and advocacy roles at the Java Community Process (JCP) which is the existing standards body for Java EE today.  We hope to continue serving the interests of the day to day Java developer in those capacities at Jakarta EE and have nominated ourselves for the corresponding working groups (Steering, Specification and Marketing).

Next Steps

Are you a day to day Java developer then please come and join us on mailing lists and have your voice heard.  If you’re unsure on what’s going on or are nervous about speaking up, then contact us at the LJC and we’ll be happy to help.


Martijn (on behalf of the LJC Standards Committee)

Hi all,

After much thought and consideration the LJC JCP Committee have cast their votes for the JCP elections (Look for the Executive Committee Elections link at  We’re making our vote public and will give our reasons according to the openness and transparency requirements for the committee.

The list of nominees for the seats are as follows (link also contains useful recordings and notes from the nominees):

There are 8 ratified seats and 5 open seats up for election.  Although it may seem like the ratified seats are shoe-ins since to the number of candidates == the number of available seats, enough no votes can make a candidate ineligible to take the seat.

Ratified Seat Vote

Freescale, Gemalto M2M GmbH, Goldman Sachs, MicroDoc, SAP, Software AG, TOTVS and V2COM all get yes votes – they are important players in the Java ecosystem.

In particular they represent:

  1. Strength in the emerging IoT market (Gemalto, Freescale and MicroDoc)
  2. The increasing importance of the BRIC economies on the ecosystem (TOTOVS and V2COM)
  3. The massive impacts on SE and EE platforms today (SAP, Software AG and Goldman Sachs).

In short, we think Oracle have chosen well and see no reason not to ratify these candidates.

Open Seat Vote

This was a very close vote as the strength of candidates was unprecedented. Here are our yes votes:

  1. Azul Systems – Azul is one of the few JVM vendors out in the marketplace. Their inclusion is vital in order to keep Java SE as an open standard and Gil Tene’s insights around thorny legal issues have proved to be invaluable to the EC.
  2. ARM Systems – The world needs Java to run well on ARM, they should be involved in evolving Java, simple as that!
  3. Hazelcast – Represent both strength in the EE space (JSR 107 and 347 for caching and distributed data grids) and also push the SE envelope with the requirements for their core product. Greg Luck is a long time experienced member of the JCP process, his expertise would be welcome.
  4. Waratek – Bring innovative new thinking about the JVM with regards to scalability and security in cloud environments with their multi-tenanted VM. As with Azul, it would be great to see other JVM vendors on the EC to keep help keep Java modern.
  5. Morocco JUG – Representing the voice of developers in the Middle East and Africa.  It’s estimated that a majority of new developers will come from these nations over the coming years and so they should continue to be included at the highest levels of Java.
  6. Geir Magnusson Jr – Geir was instrumental in helping shape Java in the early years of its existence and brings a wealth of experience and understanding of the broader Java ecosystem.  It’s great to see him back!

There were lots of other worthy candidates, but we feel these 5 candidates represent the best balance to face the challenges of the industry in 2015.


Although the Committee has voted for and endorsed these particular candidates, any LJC member who is also a JCP member can (and no doubt will!) vote any way they wish to.


Martijn (on behalf of the LJC JCP committee

LJC Election Position Paper

  • Openness and Transparency
  • Advocacy and Adopt-a-JSR
  • Technical gravitas

TLDR Summary: The LJC stands for active developer participation in standards, openness and transparency, promotion of F/OSS implementations and has no direct commercial interests in any proposed standard. We have initiated global programmes (Adopt a JSR, Adopt OpenJDK) directly involving developers in standards, improving them for the entire ecosystem.

History & Detailed Position

The London Java Community is a large (~2750) and rapidly growing group of developers who actively meet, discuss and work on the Java ecosystem.

During the 18 months we’ve been a JCP Executive Committee member, we’ve actively participated in reforming the JCP process itself and eroding the disconnect between developers and decision makers, through practical programmes and advocacy.

Our original goals were based on a few simple ideas:

  1. Openness and Transparency are essential for any functioning standards body, and the JCP must be reformed where necessary to achieve this.
  2. Better Standards are produced when ordinary end-users are fully engaged in the process of producing standards from start to finish.

As a user group, we have no direct commercial interests in the space.

Open-Source Software reduces barriers to entry for companies and reduces cost for non-commercial projects. We therefore seek to ensure that zero-cost open-source implementations of all standards are possible, and have the maximum possible patent and IP protection.

The LJC has made a major impact on the JCP, and its relations with developers and the Java community since being elected, by:

  • Being vocal advocates of reform and transparency in the relevant JSRs (348, 355)
  • Ensuring that commitments made by Spec Leads were followed through to completion.
  • Investigating JSRs which did not meet accepted standards of openness, and helping them to address any issues.
  • Founding the Adopt-a-JSR programme – to give a place for ordinary developers to get more involved in emerging standards and to start concentrating the enthusiasm and energy that exists in the community.

If re-elected we commit to:

  • Finishing the JCP reform efforts started in JSR 348 ( and JSR 355 (EC Merge) by fixing IP Flow and Licensing issues in JSR 358 (
  • Taking our Adopt-a-JSR programme to the next level by seeding new Adopt-a-JSR teams in JUGs and organisations around the world.
  • Continue to run and promote workshops, talks and global collaboration by developers on JSRs.
  • Continuing to always stand up for the interests of developers and community – including promoting open-source implementations and projects.
  • Maintain a deep bench of talent in our committee, to ensure that developers are represented with the same time commitment that a major corporation can provide.

Our Committee

The LJC operates a JCP committee. This group is made up of volunteers who have agreed to abide by confidentiality rules, meet their commitments (including time commitments) and to work towards the goals agreed by consensus. The current committee members are: Ben Evans, Martijn Verburg, Trisha Gee, Richard Warburton, James Gough, Somay Nakhal and David Illsley.

This enables the LJC to avoid problems related to key person risk – with 7 members on the team, if one person needs to reduce their level of commitment then others can pick up their workload. We have discovered that running an effective EC seat requires at least 20 hours per week – equivalent to ½ person full-time. Given the LJC’s size, we feel confident that we can continue to staff the committee at the required level to provide a real voice for developers.

Openness and Transparency

We believe strongly in openness and transparency:

  • We publish the motivation behind previous voting decisions on the LJC blog in order to ensure complete transparency and open access.
  • We also publish the minutes of our committee meetings on the blog.
  • We are active promoters of transparency for JSRs. For example, we regularly monitor all JSRs to ensure that they are meeting their obligations in accordance with JCP 2.8 (JSR 348). This means open mailing lists, issue trackers etc.

Advocacy and Adopt-a-JSR

The LJC pioneered the Adopt-a-JSR program, encouraging developers to actively participate in specifications. Involvement includes everything from trialing beta APIs through to helping define the standard and implementing the Reference Implementation (RI). We are actively involved in the standardisation of JSR-310 (Datetime), and have run hackdays for JSR-310, JSR-335 (Lambdas) and JSR-308 (Type Annotations). These hackdays provide feedback on the usability of new features to the expert group and help prepare developers for upcoming changes to the Java language.

Adopt-a-JSR also highlights to developers the relevance of the JCP, and shows how they can impact the language and ecosystem they work with. To achieve this goal, the LJC has run talks, workshops and advocacy via social media such as Twitter and Java conferences such as JavaOne, Devoxx etc.

Technical Gravitas

As a large organisation of technologists we have expertise throughout the Java Platform, from deep dive tech to blue chip enterprise development. This gives us great insight into the technical merits of each JSR. Since we seek to represent a broad cross section of the community, our voting decisions are based not on the opinions of one person, but the consensus of a committee of peers.

In Summary

Eighteen months ago, the London Java Community pledged to improve the openness and transparency of the Java Community Process if elected to the JCP Executive Committee. We promised to help bridge the gap between the decision makers and on-the-ground developers. Our voting record and active participation in the JCP show that we have made real progress towards these goals. In addition, we achieved more than even we imagined by launching and championing Adopt-a-JSR, a program that has both improved feedback to expert groups from developers, and increased involvement from the people who use Java everyday in their professional capacities.

If re-elected, we will continue actively improving the openness and transparency of the JCP, and expand our successful programs to voice the needs of developers and communities worldwide.

The LJC JCP Committee

As part of the London Java Communities efforts to help out in JSR-310 efforts, we have been working with Stephen Colebourne to gather the feedback of the community on method naming conventions that would potentially be used in the upcoming implementation. After all, it is hoped that everyone in the Java world writing systems using dates will be potentially using the API from Java 8 onwards.

The intention of this blog post is to publicise the results and to encourage you to participate in the discussion. We are at the crossroads of finalising design and adapting the already comprehensive implementation to match the requirements. Please join us on the mailgroup and continue the discussion: mail group

There are 9 public questions that will be broken down into the general responses. The response has been immense, and behalf of everyone involved with the project I’d like to take this opportunity to thank you for your participation. The total number of surveys received was 1824. These results will contribute towards steering the API changes discussed on the mailing list.

The statistics below are summary statistics for the main categories, a full CSV of all anonymous responses is available here.

1. It is planned to have an enum for the month-of-year (January to December). What should this class be called?

  • 89.21% chose the format Month – eg. Month.APRIL.
  • 8.55% chose the format MonthOfYear – eg. MonthOfYear.APRIL.
  • 2.24% gave an alternate response.

2. There will be a class representing a date on its own (no time, or time-zone). Thinking about this class, what set of methods would you prefer to use.

  • 51.07% chose getYear(), getMonth(), getDay(), getDayOfYear(), getDayOfWeek().
  • 37.30% chose getYear(), getMonth(), getDayOfMonth(), getDayOfYear(), getDayOfWeek().
  • 9.44% chose getYear(), getMonthOfYear(), getDayOfMonth(), getDayOfYear(), getDayOfWeek().
  • 2.19% gave an alternate response.

3. Thinking specifically about getDay() vs getDayOfMonth(), which of these statements do you agree with? (This was a select multiple question)

  • 23.81% chose if I saw getDay() I would assume it was day-of-month.
  • 20.33% chose I would quickly learn that getDay() meant day-of-month.
  • 19.88% chose while it is longer, getDayOfMonth() is a lot clearer.
  • 16.63% chose getDay() is not clear without reading Javadoc.
  • 15.83% chose getDayOfMonth() is too long.
  • 3.52% gave an alternate response.

4. There will be a class representing a time-of-day on its own (no date, or time-zone). Thinking about this class, what set of methods would you prefer to use?

  • 72.44% chose getHour(), getMinute(), getSecond(), getNano().
  • 13.30% chose getHour(), getMinute(), getSecond(), getNanoOfSecond().
  • 8.04% chose getHourOfDay(), getMinuteOfHour(), getSecondOfMinute(), getNanoOfSecond().
  • 6.23% gave an alternate response.
5. The month-of-year can be represented as both an int and as an enum. How should method access to this be achieved?
  • 58.29% chose only have a method returning the enum, with the int value available via a method on the enum.
  • 12.31% chose getMonthValue() returns an int; getMonth() returns an enum.
  • 8.11% chose getMonth() returns an int; getMonthOfYear() returns an enum.
  • 7.08% chose only have a method returning the int, removing the enum from the API.
  • 7.08% chose getMonthInt() returns an int; getMonth() returns an enum.
  • 3.91% chose getMonthOfYear() returns an int; getMonth() returns an enum.
  • 3.22% gave an alternate response.
6. What factors should drive the method naming choice?
Agree: 1
5: Disagree
Not sure
6.1 Shortest possible 20.45%






6.2 Pattern based 31.36%






6.3 Clear when read 65.61%






6.4 Verbose 7.61%






6.5 Unambiguous 44.14%






6.6 Quick to write 17.15%






6.7 Consistent 64.57%






6.8 Balance of short and clear 48.93%






6.9 No need to read Javadoc 32.15%







7. Too large to publish easily in the blog.

8. Have you used Joda-Time?
  • 41.48% chose never.
  • 36.34% chose occasionally.
  • 22.18% chose frequently.

9. How much experience do you have with Java?

  • 69.95% chose more than 5 years.
  • 22.94% chose 2-5 years.
  • 4.62% chose less than 2 years.
  • 2.48% chose Java is not my main language.

(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 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! 🙂

Hi all,

Minutes for 3rd Jan 2012, as always, questions, comments etc are welcome!


  • Ben Evans
  • Martijn Verburg
  • Michael Barker
  • Somay Nakhal
  • Richard Warburton


  • JSR-331 – Concerns were addressed, EG is more diverse
  • Voting record on was updated by MB
  • BE Waiting for Spec lead of 351 to set up webinar
  • TG has set up a shared calendar for early JSR reviews and dissemination of our reviews
  • Get a volunteer to introduce Raoul-Gabriel Urma to the right people in the OpenJDK for his ‘Relationships in Java’ prototype or more likely, set-up a project so people can take a look (via patches) (MB/MV)
  • JSR 344: JavaServer Faces 2.2 – Early Draft Review – (Committee to seek volunteers)
  • JSR 339: Java API for RESTful Web Services – Early Draft Review – MV found an Adopt a JSR Lead
  • JSR 346: Contexts and Dependency Injection for Java EE 1.1 – Early Draft Review – (Committee to seek volunteers)
  • JSR 342: Java EE 7 – (BE to investigate EG composition further, raise at F2F in Jan)
  • Jigsaw: – Committee to investigate progress of JEP (MV to chase Neil Bartlett / Tim Ellison)
  • Adopt a JSR materials for JUGs:
    1- MV created the overview presentation. 5 minutes on what the JSR is about and what it means for the regular developer
    2- Technical deep dive – 10-60 minutes on how to use the result of the JSR, implementation details, best practices… All a developer needs to get from “Haven’t heard about” to “Almost Guru” (MV/JG)
  • MB to lead OpenJDK Adoption and set up a monthly regular session – find a venue via BC
  • MV to investigate with Oracle about access to statistical analysis tools.
  • MV to ask JUG leaders list to assist with further JSRs
  • F2F – Ben has raised discussing all active JSRs for Agenda
Martijn (On behalf of the LJC JCP Committee)

Hi all,

We realised that at the recent Open Conference that there were a lot of new faces to the LJC. It has been 6 months since we won the elected seat for the JCP Executive Committee (EC) and formed our own committee to review and vote on JSRs (and deal with any other JCP activity).

There have been a number of posts to this list on the topic of the committee and it’s activities, but we thought we’d better bring it all together under one post with regards to how it came to be, its structure and how you can join in!

What’s the goal of this Committee?

  1. Primarily we want openness and transparency in the creation of Java Standards.
  2. Equally as important, we want the end users of these standards (that would be Java developers) to have a say in the standard before it becomes ratified.

What if I don’t agree with the committee?

We don’t own anybody!

The reality is that with >2000 members, all we can do is try to represent you as best as possible. We do this by canvassing opinions, especially at events such as the developer sessions, talks and of course, the recent open conference. You’ve probably also seen the regular blog posts and mails asking for feedback as well.

‘Adopt a JSR’ is yet another feedback mechanism we have in place.

We especially want to hear from you if you do disagree with us! The wide range of opinions we have, the more accurately we vote for the community at large. And of course you can join the committee and add your direct vote (see “How do I join?” below).

Who’s currently on the Committee

  • Ben Evans (The designated rep for JCP EC meetings)
  • Martijn Verburg (secondary rep)
  • Trisha Gee (tertiary rep)
  • James Gough
  • Richard Warburton
  • Simon Maple
  • Michael Barker
  • Somay Nakhal

And of course Barry Cranford keeps his hand in as the Founder of the LJC and keen ‘Adopt a JSR’ supporter.

How did this committee form?

We originally sent out several posts asking for volunteers for the LJC JCP Committee. The initial group of people that volunteered was Ben Evans, Martijn Verburg, Trisha Gee, Simon Maple & James Gough. Michael Barker, Richard Warburton and Somay Nakhal have been added since (see “How do I join?” below).

How do I join?

The JCP Committee consists of a “meritocracy of the willing”. That is, if you want to join and are willing to put the effort in then after a couple of monthly meetings the committee adds you in (after a simple majority vote). So far everyone that has wanted to join has been accepted, we’re very much an open shop on that front!

The barrier to entry is relatively low. The minimum requirement is that you put in some effort – that is:

  1. Regularly turn up to the monthly meetings
  2. Actively review JSRs
  3. Support programs such as ‘Adopt a JSR’
  4. Write the occasional blog post

It helps to have a good understanding of the overall Java ecosystem and some open source and software patent laws, but we can mentor people in all of those areas. The time effort required is typically about 5 hours a week for a committee member, with the JCP EC reps putting in extra hours for EC meetings and extended research (10-20 hours/week).

Travel is required for the primary rep (or the appropriate back up) for a F2F meeting 3-4 times a year. As we are a Java User Group – Oracle picks up the flight and accommodation expenses for that rep (we’re talking economy class and a reasonable hotel, so this isn’t the 5* perk the rep was looking for ;p).

How does the committee vote/organise itself?

Simple majority voting applies, this includes voting who the primary, secondary & tertiary reps are and voting on JSRs etc.

Is the mailing list public?

Sadly not. This is the unfortunate reality of discussing legal issues (under NDA in some cases) and other information that the committee is given in strictest confidence.

So what do you make public then?

Everything that we possibly can! So our minutes (with some legal stuff redacted), our voting strategy and record. We’re certainly the most open and transparent member of the JCP EC and are encouraging the other members to follow suit.

Hopefully that answers most people’s questions but of course any and all feedback is welcome!


Martijn (on behalf of the LJC JCP committee)


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

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.