Geertjan is a DZone Zone Leader and has posted 468 posts at DZone. You can read more from them at their website. View Full User Profile

Interview: Game Over for the JDK's Date and Time Classes

05.05.2008
| 9730 views |
  • submit to reddit

JSR 310 aims to modernize the date and calendar classes. The goal is to provide a more advanced and comprehensive model for date and time than those found in the Date and Calendar APIs. The JSR's leaders, Stephen Colebourne and Michael Nascimento, are presenting their work at JavaOne and give an overview below.

Firstly, please briefly introduce yourselves.

Michael Nascimento. I'm a senior technical consultant at Summa technologies and the founder of the Genesis open source project. I have also served as an expert on a few JSRs, such as the Common Annotations for the Java Platform (JSR-250).

Stephen Colebourne. I am employed building travel e-commerce booking engines and am involved with many open source projects, such as Apache Commons and JodaTime. I am involved in this JSR because of my JodaTime project.

JodaTime? What's that?

Stephen: JodaTime provides a complete replacement of the date and time classes in the JDK:

public boolean isAfterPayDay(DateTime datetime) {
if (datetime.getMonthOfYear() == 2) { // February is month 2!!
return datetime.getDayOfMonth() > 26;
}
return datetime.getDayOfMonth() > 28;
}
public Days daysToNewYear(LocalDate fromDate) {
LocalDate newYear = fromDate.plusYears(1).withDayOfYear(1);
return Days.daysBetween(fromDate, newYear);
}
public boolean isRentalOverdue(DateTime datetimeRented) {
Period rentalPeriod = new Period().withDays(2).withHours(12);
return datetimeRented.plus(rentalPeriod).isBeforeNow();
}
public String getBirthMonthText(LocalDate dateOfBirth) {
return dateOfBirth.monthOfYear().getAsText(Locale.ENGLISH);
}

What are the main things that are wrong with the current date and time classes?

Stephen: The existing classes are pretty bad—probably the worst APIs in the JDK. They're buggy, mutable, cumbersome, many bugs, and they tend not to be threadsafe.

Michael: The original date class comes from JDK 1.0. At the time, James Gosling tried to follow the related functions in C and didn't put much force into designing them from scratch. For example, they can't be internationalized and only local timezones are supported.

Stephen: Right. The Gregorian calendar class is a direct port of the C-class, such as "January = 0". So, if you enter the month "12", the month is January because the algorithm wraps around. The algorithm performs calculations such as this that you don't expect. For example, with the Gregorian calendar class, getYear(), getMonth(), and getDay() are quick, while if you call combinations of getyear(), setyear() (and getMonth() setMonth(), and so on), performance will be bad because lots of calculations are done unexpectedly. Politely put, one can describe these classes as exhibiting "unusual performance characteristics".

Why has it taken so long to fix these various problems?

Stephen: People have known of these problems for several years. Some attempts have been made to fix the Calendar class, but it only got worse. Fixing these issues once and for all has never been a high enough priority.

So why now and why you?

Stephen: I started JodaTime in 2000/2001 and gradually solved the standard date and time class problems, releasing it in 2003. My solution has been picked up across the board, from small applications to the largest advertizing systems in the world. The point is that I wanted the solution to exist a few years as JodaTime, before heading into a JSR so that all the issues would have been identified in preparation for the JSR.

In a nutshell, what does JodaTime offer me?

Michael: Firstly, a better quality API.

 

Stephen: Secondly, JodaTime supports a number of additional concepts. Firstly, "periods", such as if you wanted to store the concept of 5 weeks and 3 days. Secondly, "intervals", so that you'll be able to store the interval between the start of JavaOne and its end, i.e., for example, from Monday May 5, 9 a.m. to May 9, 3 p.m. Thirdly, an updated timezone implementation to make it easy to pick up timezone changes, which could even be on an annual basis. Finally, handling of different calendar systems, such as Islamic calendar systems / Coptic calendar systems, and so on, which don't exist in the standard JDK.

Michael: The third point is why I got interested in this JSR in the first place. I'm from Brazil where the daylight saving systems change each year and there's always one or two weeks of chaos. I asked myself why things go wrong every year around this issue.

Stephen. Possibly we could offer a solution consisting of a JAR file with the latest set of rules, which you could then put on the classpath. However, sometimes you'd need both sets of rules at the same time. We're still thinking about these situations and ought to be able to come up with something.

By the way, where does the name "Joda" come from?

Stephen: "Joda" was a 4 letter domain name starting with "J" that was free in 2003. I simply typed random things beginning with "J" and found that that one was free...


Where is the JSR process now?

Michael: We are progressing it in an open manner. All discussions are on public mailing lists and Wikis. All repositories are open and Issuezilla is open.

Stephen: We are using java.net to build a reference implementation and a testing kit in Subversion. People can go there and try it out. It is all "work in progress". The basic API is there. Right now, parsing needs to be finished and some loose ends need to be tidied up. Parsing, intervals, and multiple calendar systems are missing at the moment.

Can you say something about the JSR's timeline?

Stephen: We hope that we'll be in Java 7, but given that there's no date for it, there's no guarantee that we'll finish in time. We received a little bit of funding from the OpenJDK challenge to get to early draft review by August.

Michael: It's really important that people get involved, the last chance to influence design aspects is the early draft review, scheduled for August, which is coming near. Two previous attempts have been made for rewriting these classes and it's unlikely there'll be another one after ours. So it is really important to let your voice be heard because the more feedback we get the better.

Stephen: There's been good quality feedback. We've had suggestions consisting of sample implementations of intervals, people pointing to different ISO specifications, and suggestions to expand into areas outside our scope. People should take a look at the algorithms too. Maybe someone could come up with better algorithms than those that we already have.

Michael: We've also been nominated for a JCP Program Award, probably because we're the main examples of individuals, rather than a company, leading a JSR. The results will be announced on Tuesday during JavaOne.

Will you present something around your JSR at JavaOne?

Michael: Our technical session on Thursday at 1.30 is completely full and there's a repeat session on Friday at the same time, that is, at 1.30. In the session, we will cover all the basic classes, show examples of the code and how to get started with it.

Stephen: There'll be little bit of explanation around the design principles, with examples of how bad the current date and time classes are. There'll also be a small puzzler, asking participants to identify the number of bugs in an existing bit of JDK code...

 

Further Reading

AttachmentSize
stephen.png718 bytes
michael.png2.21 KB
Published at DZone with permission of its author, Geertjan Wielenga.

Comments

David Gilbert replied on Mon, 2008/05/05 - 11:06am

Excellent initiative! It's great to see some individuals driving something through the JCP in an open fashion, and it will be nice to have additional / broader APIs for modelling date/time values. But I wouldn't give java.util.Date and GregorianCalendar too hard a kicking - within the scope of what they are designed for, they offer pretty powerful date/time handling facilities. I've certainly found them useful over the years. There are little quirks here and there (JAN = 0, for example), but in the scheme of things those quirks are not significant. I'm not saying JodaTime can't or won't offer an improvement, just that the existing stuff isn't all that terrible.

Steven Baker replied on Mon, 2008/05/05 - 10:26pm

there is nothing wrong with the current java Date, matches it's scope perfectly.

the last thing java needs is another one of it's core classes destroyed by becoming bloated and tedious.

leave it how it is, if you want specific junk like this, then wrap it or write your code properally rather than relying more on other people's work than your own. 

Berry Crawford replied on Tue, 2008/05/06 - 1:57am

I agree the date stuff is the worst API in Java.  i cringe whenever I need to do something non-trivial.  The JCP sounds like a cool endevor.

Fabrizio Giudici replied on Tue, 2008/05/06 - 5:42pm

Well, I've just found the usual bug with Date messing up with the timezone (obviously the thing worked at home and it's revealing to be broken here in San Francisco). I really hope that JSR-310 makes its way into Java 7. I don't know whether I'll be able to attend the J1 talks (both instances conflict with my schedule), eventually I'll ask to the mailing list, but I'd like to start refactoring my code using JSR-310 as soon as possible.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.