After spending all day Monday in the Hilton, I wasn't too surprised when my first session on Tuesday brought me back to the Hilton. Stephen Colebourne and Roger Riggs and presented "From Instants to Eras, the Future of Java" in the Hilton Yosemite A/B/C conference room. This presentation was high on my list of those to see because, after lambda expressions, the new date/time API is the feature of JDK 8 that I'm most looking forward to. Indeed, as Mark Reinhold stated in the Technical Keynote when trying to soothe concerns over the booting of Project Jigsaw to JDK 9, lambda expressions and the Date/Time API are among the many changes coming in JDK 8 that still make it an exciting release.
Colebourne showed an image of complicated clock machinery and stated that the photograph is representative of the complications inherent in attempting to write a satisfactory date/time for Java. He, of course, had a plug for Joda Time, which is the inspiration ("similar, but not identical") for JSR 310. He pointed out that JSR 310 was approved back in January 2007, but it is expected to be Feature Complete (M6) by January 2013. I agreed with his point that it's better to take time putting this in rather than to introduce yet another unfinished or poorly finished API into the SDK (think Date and Calendar).
Colebourne covered several design principles behind the new date/time API. These include fluency, immutability and thread safety, extensibility, IDE friendliness, clarity, and more.
Colebourne showed a colorful slide with numerous words and concepts sprinkled throughout. The point is how many different terms, concepts, and meanings there are in the date/time space. One of his bullets pointed out, "'time' is overloaded with many meanings." One of the goals of JSR 310 is to "define a consistent language for the domain" and "help teams communicate."
In the end, JSR 310 faces "two core requirements": machine time and human time. Continuous incrementing numbers (think milliseconds since epoch time) work well for machines while field-based dates/times work better for humans.
One concept in JSR 310 is the "Instant" (single instantaneous point on the timeline). Another named concept is "Duration" (amount or quantity of time not connected to a timeline, but it is a difference between two Instants). Both Instant and Duration are measured in nanoseconds. Colebourne showed a slide with several code examples using Instant and Duration and performing operations on each in terms of the other.
"Colebourne went on to address the "weird" aspects of date/time: "There is such a time as 23:59:60." He talked about leap seconds and "real life." He pointed out that, "The length of a day changes, but the length of a second does not change." Java's current implementation counts milliseconds since 1970-01-01 (Java's epoch time), but "UTC only started properly at 1972-01-01" (scientists' current definition at this time).
To address issues like these, JSR 310 defines "Java time-scale relative to civil time." "Civil time" is currently UTC, but by having a different name, it can be associated with anything that might replace UTC in the future. He stated that "Midday always matches civil time exactly" and that a Day already has 86640 sections.
A LocalDate is a "date without reference to time or timezone." Colebourne pointed out that this is better than trying to set java.util.Calendar to a date with 0 for hours, minutes, and seconds. Similarly, LocalTime is "a time without reference to date or timezone." Combining these two together creates a LocalDateTime (no timezone).
Colbourne talked about timezones and JSR 310 classes such as OffsetDateTime. As a "date and time with an offset," TimeZone class represents a timezone offset AND "figures out daylight savings," but JSR 310 splits up these two responsibilities into separate classes. One useful class in JSR 310 is the ZoneResolver, which uses the Strategy Design Pattern to deal with difficult/weird timezone issues. The ZonedDateTime class combines all of this into a single class supporting dates, times, and timezones.
Other classes and enums in JSR 310 include Year, YearMonth, MonthDay, Month, DayOfWeek, and so forth.
Because JSR 310 objects are immutable, they provide "with" methods rather than "set" methods. The "with" methods return a new instance based on the target instance modified by the value passed to the "with" method. Colebourne likened this approach to that used by String.lowerCase().
Riggs talked about integrating the JSR 310 implementation into the Java SDK. While JSR 310 concepts and constructs will show up in Calendar, the current plan is to prevent "pollution" from Date and Calendar creeping into the JSR 310 constructs. I definitely think this is the correct approach.
Riggs also discussed JDBC and database support for JSR 310. His bullet stated that "JDBC group represented on JSR-310." He showed a mapping of JSR 310 classes to JDBC classes.
Riggs explained the Period class, which "describes duration in human fields." The main differentiation I see between Duration and Period is that the former supports machines and the latter supports humans. [Later Update: An audience member asked about the difference between these two concepts and Colebourne answered similar to what I assumed, but he added that there is a more subtle difference: duration takes into account Instant timeline (timezone considered) while the period takes into account the clock on the wall (timezone not considered).]
Riggs returned to the concept of the "current 'civil' calendar," which is based on ISO-8601. They are working on a calendar-neutral system for using non-ISO calendars and lookup the alternate calendar systems by name ("Coptic", "Hijrah", "Japanese", "Minguo", "ThaiBuddhist"). As currently implemented, this non-civil support is only available for dates. All of these are convertible to the ISO ("civil") standard.
One of the difficult things that Riggs talked about related to regional calendars is the concept of eras. Chronology and ChronoDate support methods for dealing with eras and other less common date measurement concepts. A goal of JSR 310 is to be extensible so that new calendars can be added.
So far, I like what I've seen from JSR 310 related to handling different calendars. It is obviously nice to allow support for anyone's preferred calendar, but it seems silly to make everyone deal with strangeness and difficult APIs to accommodate a minor fraction of developers (think Calendar interface). The JSR 310 approach seems to provide easy-to-use APIs for the majority of developers while not precluding developers needing special cases from having the support they need.
Riggs showed a code example of acquiring Instant that used the Clock class to initialize the Instance instance. JSR 310 retains its immutability in its date/time formatter called DateTimeFormatter. There are common formatters in DateTimeFormatters and an ISO-8601 compliant string is returned by toString().
The core date time model, according to Riggs, consists of the DateTime interface and the AdjustableDateTime interface.
Rigg's slide on "Open Issues" was also interesting. They would like to use Java 8 (Lamba) features. They also still need to work out details of the Period to SQL mapping. They have several design issues still to address. One of their next steps is to integrate ThreeTen (JSR 310 reference implementation) into OpenJDK. Other "next steps" are "more implementation" and "more unit tests." Finally, they need "review by OpenJDK reviewers."
As with many other sessions at this JavaOne, Riggs mentioned that JSR 310 is open ("very open!") and listed some ideas for community help (joining mailing list, comment on Wiki, reviewing the API). Colebourne reiterated the point about its openness and the desire for community feedback.
Before answering audience members' questions, Colebourne had some questions for the audience. My guess is that he was looking for community feedback on certain design issues. One of his questions was how many people using a production system used a date older than 1900. There were, surprisingly, several of these. However, only one person answered the second question affirmatively (how many of you have used a non-ISO calendar system in Java?). This is not surprising to me, but audience members made a good point that this should be asked in JavaOne in Brazil, Japan, and Thailand.
In response to an audience member's question, Colebourne said he plans to update Joda Time to implement JSR 310 interfaces, giving developers an option to use those implementation classes rather than the JDK classes (and an easier way to migrate if necessary). He mentioned that a disadvantage of this is that there will be class name clashes requiring fully specified package names in some cases.
Although this session was decently attended (room was about 20% full), I was surprised that it wasn't much more full than it was given the significance of this change, given the itch that it scratches, and given that it is one of the more exciting features of forthcoming JDK 8. Like Lambda, this seems to be maturing nicely and I doubt that much that is learned now will be wasted (will change dramatically before the JDK 8 release). Riggs called JSR 310 a "very robust, very complete" API for handling date and time and that definitely seems to be the case.
The questions in the question and answer section proved that while the audience was smaller than I had anticipated, there are still many people very interested developers in attendance. There were lots of great questions that showed familiarity with the pains of date/time and interest in the new API.
Like The Road to Lambda, this presentation met my expectations and left me excited about its subject matter. Some have stated that JDK 8 should not be delivered without Jigsaw, but my feeling is that Lambda and JSR 310 alone make JDK 8 well worth delivering as soon as possible.
1 comment:
Nice blog.......
Post a Comment