Probably everyone is exited that Oracle is finally picking up the highly dubious date time implementation in Java called Calendar. It is interesting to see that large companies like Sun really have problems getting something as seemingly simple as date and time implemented correctly. Of course there are two sides to the problem, first there are all the intricacies of date and time, like time zones and other more or less subtle problems (this is where Date went wrong). And secondly there is the implementation aspect, where for 99% of the usages a date or time is considered an immutable value, like a number, easy to use for a developer (this is where Calendar went wrong, just take a look at the output of toString()).

Now, there are reasons why there is a CalendarPicker and not a DatePicker in JFXtras. And the primary reason is that Calendar has a notion of locality, which Date has not; for example in Germany the week starts on a different day (Monday) than in the USA (Sunday).

Calendar actually is pretty decent when it comes to the domain of dates and times, Jodatime is added to Java 8 is because the implementation, the API, is bad.

Jodatime takes a little getting used to API wise, using methods like “plusDays” which feels domain-driven style and deviates from what a Java developer would expect IMHO, but it definitely is a big improvement for the developer. And Oracle is smart to use a mature and proven open source library as part of JSR310, instead of trying to reinvent the wheel itself. I hope Oracle will stick to this approach and simply standardize what is proven to work (*cough* layout *cough*).

Anyhow, when people started to ask if there would be a LocaleDateTimePicker in JFXtras a choice had to be made.

1. Create a two totally separate controls.
2. Implement one control and use it in the other.
3. Extend one control and add the missing logic.

For the initial implementation I went for approach 1, it also was a great way to get to learn Jodatime better; so I copied over the CalendarPicker java files, and converted them. It turned out that after replacing all Calendar references with LocalDateTime, all I had to change were a few supporting methods that contain the Locale related code. In essence 90% of the code stayed the same. This approach would leave me with two almost identical implementations to support, and I had not even started on the other Calendar controls.

Considering the second approach also had some drawbacks. The controls contain more than just a Calendar value; they also have callbacks and other properties, and each property needs to be duplicated into the new control and bound to the encapsulated control. This again results in duplicate code, but way less than in approach 1. I think this approach is conceptually the best, but the CalendarPicker is still under active development (it’s in JFXtras labs after all), and I regularly add some functionality to support a certain use case. Also lately my time is very limited with all kinds of money earning related stuff.

So when the latest functional addition to the calendar controls came along, I decided for option 3; let the JSR310 controls extend the calendar controls and add a LocalDateTime property. In controls of about 100 lines, I can add support for JSR310, and any improvements are picked up automatically. The only drawback is the fact that the JSR310 controls have a calendar property, but I figure that is a small price to pay (for now). Developers simply should not use that property, because in the future -when things have stabled out-, the calendar properties will be removed. But at the moment it allows for easy migration; the JSR310 controls are drop-in replacements for the calendar controls, and the user can slowly change his code to use the new date API.

So please take a peek at:

• LocalDateTimePicker
• LocalDateTimeTextField
• LocalTimePicker
• LocalTimeTextField

And let me know if they work out for you.