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

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.

Recently, the London Java Community was elected onto the JCP (Java Community Process) board. The JCP is the mechanism for developing standard technical specifications for Java technology. The London Java Community’s membership on the board enables us to deliver content on upcoming and in-progress Java Specification Requests (JSRs) back to our growing community. It also gives us the unique opportunity to engage people working on the JSR projects and developers who have expressed an interest in contributing. We’re currently trailing the process of adopting a JSR. Although the process has not yet been fully defined, the first example we have selected is JSR-310, an improvement to the Java date system. Last month I presented a lightning talk on the topic of JSR-310 and Java Dates. This blog post will go into detail on some of the current limitations of dates in Java and will discuss how you can get involved in the ThreeTen project. The London Java Community JCP group believes this is an important JSR and will lead to an improvement to all developers using Java. If you are interested in finding out more about the LJC/LCP committee please contact @kittylyst on twitter, or drop me an email for more information.

Dates are a critical part of most software applications. Data models that represent something in the real world nearly always depend on timings or times of occurrence. Originally, Java had the Date class. There are a number of good discussions that have documented the limitations of the original Java Date class. One of the largest issues is that dates are mutable and therefore not thread safe, leading to an immediate issue surrounding scaling out applications that make use of Dates. Furthermore, Date is a DateTime, but confusingly there are also wrappers around Date in java.sql package for this. The functionality in Date and sql.Date are so similar that, especially for new developers, it can be unclear when and where to use each. Finally, there is no support for TimeZones in Java Dates, so building systems running in different regions and converting back to a centralised TimeZone was very complicated before the introduction of the Calendar class.

The Calendar class was added to the language later for TimeZone support and for more complex date problems. The problem with calendar was that it was still mutable, and formatting a date directly from a calendar was impossible – once again pushing the developer to understand the exact details of each implementation and when to use each.

The following code example is from a presentation given at JavaOne several years ago which highlights the above in one code fragment. A simple and readable piece of code shows 6 different bugs:

//Bug 1, 2007 although you think this is the date you actually need to subtract 1900 to get the true representation
//Bug 2, 12 dates are indexed from 0 so, in this instance, 12 is out of bounds
Date date = new Date(2007, 12, 13, 16, 40);
//Bug 3, The timezone isn’t the ISO standard and requires and underscore to be correct
TimeZone zone = TimeZone.getInstance(“Asia/HongKong”);
//Bug 4, can’t create a Calendar from a date, you need to use a static instance of and then apply the date
Calendar cal = new GregorianCalendar(date, zone);
DateFormat fm = new SimpleDateFormat(“HH:mm Z”);
//Bug 5 and 6, can’t format on a calendar or a calendar object like this
String str = fm.format(cal);

Joda Time

Joda Time introduced several new key concepts into the Date arena that make working with Date and Times far simpler from a programmer perspective.

  • Instant – There is a Joda-Time class of “Instant”. “DateTime” is also an instant, but one that adds getters for the human fields. DateTime is immutable and therefore thread safe. Immediately we have a good replacement for Date.
  • Interval – An interval is a time measured from one instant to the another. The limitation here is that both end points are in the same Chronology and TimeZone.
  • Duration – Duration is simply an amount of time measured in milliseconds, no timezone or chronology applies to a duration
  • Period – A period of time time defined in terms of fields. This is a really useful feature for working with dates from a human aspect. Whilst machines represent underlying dates in long numbers, we still split things down into months, days and hours. Consider saying “one month from now” in February and then saying the thing same in May. Even though the month is the same, the underlying number of days varies. Periods allow the programmer to specify this kind of logic without having to convert to seconds and then add these to the value of the object.
  • Chronology – From the developer perspective, a chronology is under-the-hood and is the calculation engine which holds the complex calendar rules. In most cases this, is is ignored as most users will be using ISO Chronology.
  • TimeZones – A representation of the TimeZone held within a DateTimeZone class.

JSR 310

JSR-310 builds on many of the concepts that were introduced in Joda Time. However, to have the most robust implementation available for Java, there are some key issues in Joda Time that had to be addressed in JSR 310. So Joda Time is not without its flaws, but this doesn’t mean it shouldn’t be used; it’s currently the best production ready system there is. Stephen Colebourne covers this in his blog.

Human and Machine Timelines – I was born on 29th September 2005, this is a human representation – a Java representation is the number of milliseconds since 1970-01-01T00:00Z. JSR 310 separates the concepts out in the underlying implementation to make intent clear.

Pluggable Chronology – This can introduce unexpected state to the system by its pluggable nature. Consider calling the month of the day, you could get 13 if the chronology was incorrectly set. It is likely that people don’t check this before they make the call. Keeping these things separate is good programming practice leading to better unit testing and fewer curve balls when debugging problems later.

Nulls – The treatment of null values is always up for debate, nulls could be treated as the epoch, rather than a null value. Having this fuzzy behaviour could lead to bugs where you simply didn’t realise that you had passed a null by hiding errors. JSR-310 will seek to treat nulls as exactly that, and not assume they are the epoch.

Internal Implementation – Most user interacting with dates may not realise the depth of the implementation that is required around such a system, for example most people will use standard chronologies and calculations with dates. However, the internal computations are complex, especially when coupled with chronologies and the human machine timelines. Ensuring this architecture is production standard for all users is not a simple task.

In JSR 310 some key decisions were made to move Joda Time forward by reworking some of the design concepts. What the user sees in the Joda time API is the tip of the iceberg. A lot had to change in order to have these design considerations in place.

The main issue that might compromise the inclusion into Java 8 will be around the TCK testing suite, which is likely to be required in addition to the unit tests provided with the current ThreeTen implementation.

Getting Involved

The ThreeTen project (the reference implementation of JSR-310) is now on GitHub, so contributions can be made and pulled into the project. ThreeTen is developed entirely in the open and there are still a number of things to be done. Contributions around documentation, testing and performance optimisations are currently up for grabs. One such example would be working out the best way to derive the OffsetDateTime from an instant.

Getting involved is as easy as entering a few git commands and joining the mail group.


JSR 310 is currently one of the key JSRs and any additional community support should help ensure that the project enters the earliest version of Java possible.

Jim Gough

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.