sábado, noviembre 27, 2010

La Mer Au Ciel d'Ete Confond


Have you ever started a war with java.util.Calendar class? I hope no, but unfortunately a lot of developed applications deals with Date and Time. Calendar class is a singleton class for manage time, but one never knows exactly how to work with it. You know you have methods for add and subtract time, but nothing more. Now I ask, How about periods of time, durations, intervals...? you need to develop a class for managing all these requirements. Let's take an example:

Imagine we want to compare if current date is Christmas Date.

Calendar compares all its fields, so year, month, day, minutes, seconds, ... are compared, but wait, Christmas day does not depend on year, every year has its Christmas Day. So a "Util" class is developed for treating with this situation. This class would look something like:

Calendar christmasDay = Calendar.getInstance();
christmasDay.set(MONTH, 12);
christmasDay.set(DATE, 25);

Calendar now = Calendar.getInstance();
if(christmasDay.get(MONTH)==now.get(MONTH) && christmasDay.get(MONTH)==now.get(DATE)) {
return true;
} else {
return false;
}

Next example:

Boulangerie example. Our brother-in-law have a bakery, and wants to automatize oven, so a each bread stays only 15 minutes inside oven (of course not all breads gets into oven at same time). With Calendar/Date class this logic would look something like:

static long FIFTEEN_MINUTES = 15 * 60 * 1000;

long startOvenTimeBread1 = System.currentTimeInMillis();
//Thread Polling
....
long currentTime = System.currentTimeInMillis();

if(currentTime>=startOvenTimeBread1 + FIFTEEN_MINUTES) {
//bread ok
}

As you can see first example it is tedious because you must get all required attributes, and compare them with current time. In second example is not as hard as first but you lost the sensation of working with time, all are longs, and the only way to understand what is each long is with variable name.

So Yes working with Dates/Times in JDK looks like a suicide, but here comes JSR-310 (JDK-8?included).

Let's rewrite the same examples but with JSR-310 API.

Christmas Day example:

MonthDay christmasDay = MonthDay.of(12, 25);
MonthDay now = MonthDay.nowSystemClock();

boolean isChristmas = now.equals(christmasDay);

I think more readable than using Calendars, no problem with hours, minutes, seconds, years, ... MonthDay class manages all. These kind of classes in JSR-310 are known as Partials because they only represents partial time.

Now Boulangerie needs our help. As you have observed, the first problem in that case is that you only manages longs, and as a developer you don't have the feeling of working with time. Also an ugly comparison is required.

How make code looking better:

Duration duration = Duration.ofStandardMinutes(15);

Instant insertedBreadInstant = Instant.nowSystemClock();
Instant bakedBreadInstant = insertedBreadInstant.plus(duration);

//Thread Polling
...
boolean isBaked = bakedBreadInstant.isBefore(Instant.nowSystemClock());


Well more instructions than long approach are used, but don't you think that this implementation is easily read, and you know what is each field.

So don't you think JSR-310 specification and RI implementation is a really useful API? more powerful than current Calendar/Date classes.

Now it is only time to wait for being built-in JDK, but of course you can download RI implementation from java.net.

6 comentarios:

Frank Stolle dijo...

For this people who want to get source of RI, here is the link:

http://java.net/projects/jsr-310/

afsina dijo...

Actually no, JSR 310 is moved to http://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen
ThreeTen Project.

Alex dijo...

Thank you for reading the post, I am opening an account to GITHub for posting source code of the examples.

ngirardin dijo...

Joda-time is a fairly descent library to reduce the pain when dealing with dates and time in java. It's used by the excellent playframework, you should give a try to these two!

Alex dijo...

Joda time is really good, in fact creators of Joda time are also in JSR specification, they say that because of the mistakes they have done in Joda time they are trying to do a better API. I must say that if I should start a new project for dealing with Date/Time I will choose Joda time because of stability, but always jeeping an eye to JSR-310

Unknown dijo...

d7i07p6n33 q7y75h9v01 a7u82s3t50 b1y67u3w35 o7r61i3h36 m8n19f6z95