InfoQ

News

Date and Time API: Round 3

Posted by Craig Wickesser on Oct 13, 2008

Community
Java
Topics
JCP Standards ,
Language Design
Tags
Java SE ,
JSR 310
Nearly two yers ago a Java Specification Request was filed to provide a much needed overhaul of the Date and Time API for the Java platform. The official request has been logged as JSR 310: Date and Time API. As documented in the specification request the goal is to,
...build upon the lessons learned from the first two APIs (Date and Calendar) in Java SE, providing a more advanced and comprehensive model for date and time manipulation.
There are three areas identified that the new API will aim to improve:
  1. A data model for dates and times that provides much more than the existing Date and Calendar.
  2. Date and Time issues including formatting, parsing, serialization and persistence.
  3. Simple to use API.
The new API is expected to be included in a javax.time package and at the time of this writing includes over 90 classes, a significant effort over the existing Date and Time API. Jesse Farnham provided a thorough explanation of the proposed API and is worth reading to get a better grasp of what the API will look like and provide.

For additional information check out the following links:

17 comments

Watch Thread Reply

Two years by Roland Carlsson Posted Oct 14, 2008 1:09 AM
90 classes - simple to use? by Thomas Mueller Posted Oct 14, 2008 1:28 AM
Re: 90 classes - simple to use? by Jonathan Allen Posted Oct 14, 2008 2:45 AM
Re: 90 classes - simple to use? by Jonathan Allen Posted Oct 14, 2008 2:57 AM
Re: 90 classes - simple to use? by Miguel Ping Posted Oct 14, 2008 4:32 AM
Re: 90 classes - simple to use? by D Alexander Posted Oct 14, 2008 6:24 AM
Re: 90 classes - simple to use? by Jonathan Allen Posted Oct 14, 2008 10:59 PM
Re: 90 classes - simple to use? by Francois Ward Posted Oct 14, 2008 9:22 AM
Re: 90 classes - simple to use? by Olivier Allouch Posted Oct 14, 2008 9:53 AM
Please help me by ahm alz Posted Feb 17, 2009 4:09 AM
Re: 90 classes - simple to use? by Mileta Cekovic Posted Oct 14, 2008 3:54 AM
Re: 90 classes - simple to use? by Thomas Mueller Posted Oct 14, 2008 6:26 AM
Re: 90 classes - simple to use? by Dave Rooney Posted Oct 14, 2008 7:47 AM
Re: 90 classes - simple to use? by Thomas Mueller Posted Oct 14, 2008 8:33 AM
Re: 90 classes - simple to use? by Rob Elliot Posted Oct 14, 2008 10:35 AM
Re: 90 classes - simple to use? by Stephen Cresswell Posted Oct 14, 2008 3:09 PM
A really huge solution by jeason Zhao Posted Oct 14, 2008 3:19 AM
  1. Back to top

    Two years

    Oct 14, 2008 1:09 AM by Roland Carlsson

    Too bad that the JSR-processes are so slow. Perhaps it would be better to deliver a smaller, less perfect 1.0 version and then be able to improve on it later and depricate (and perhaps actually ditch the old ) things that wasn't perfect to start with. Not that I ever would imagine to say that Microsoft's "we get it right to version 3 or 4" is the way to go but it seems to work quite well for them.

  2. Back to top

    90 classes - simple to use?

    Oct 14, 2008 1:28 AM by Thomas Mueller

    JSR 310 is _much_ too complicated. It is grossly over-engineered. There are so many 'ease of use' features that it is actually very very hard to understand and use.


    How can you replace 2 classes with 90 classes? Who needs classes like 'Years', 'Weekyear', 'MilleniumOfEra'?


    Please, please, please simplify!

  3. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 2:45 AM by Jonathan Allen

    Actually I need some of those. The FIX protocol has weird stuff like a field that can be a week-year, week-month-year, or a true day-month-year. This partial date stuff is important and a pain in the ass without library support.

  4. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 2:57 AM by Jonathan Allen

    I take it back, the spec is insane.

    For example:

    Period p = periodBuilder().years(2).days(5).minutes(30).build();

    Instead of something sane like a constructor, we have to deal with a completely separate object?

    This is the kind of silliness that makes people think Java is bloated.

  5. Back to top

    A really huge solution

    Oct 14, 2008 3:19 AM by jeason Zhao

    90 Classes! What a huge solution.

  6. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 3:54 AM by Mileta Cekovic

    Well, number of classes is not the measure of simplicity, but the way these classes are used. If you want to do simple things, API has to enable you to do it simple way. If you want to do complex things API has to enable you to do it too, but of course, this time it could be more complex, as the nature of the problem is more complex.

    In my opinion new Date and Time API does both. Note that date, time, period, interval etc. are valid and essential date/time manipulation constructs and are indeed needed, otherwise old Date and Calendar would be sufficient.

  7. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 4:32 AM by Miguel Ping

    If you have worked with complex date and time functionality (I don't even mention other calendars like the Chinese which is lunisolar... This is important, just realize how many people use the Chinese calendar) you'll see that Time and Date are concepts that are very difficult to condense in a simple solution. I haven't looked at the api but I know it's a hard job.

  8. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 6:24 AM by D Alexander

    @Jonathan

    What's insane about that?

    I'd much rather maintain:

    Period p = periodBuilder().years(2).days(5).minutes(30).build();

    than

    Period p = new Period(2, 5, 30);

  9. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 6:26 AM by Thomas Mueller

    "Make everything as simple as possible, but not simpler."

    > number of classes is not the measure of simplicity
    Somebody new to the API is lost.

    > the nature of the problem is more complex
    The nature of the problem is actually quite simple: You need a date (maybe a time and timestamp), an interval, a calendar, a timezone.

    For example, why are "MilleniumOfEra", "SecondOfDay", "WeekOfWeekyear" (and so on) a class? They should be methods (a setter and a getter). Actually things like "Millenium", "DecadeOfCentury" are not required at all. For most people the concepts 'Durations', 'Periods', and 'Intervals' will be confusing. I don't think this distinctions is required. Also 'Partials' are not required.

  10. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 7:47 AM by Dave Rooney

    Thomas,

    You sound like you have some good ideas. The Open Source mantra is, "if you don't like it, fix it!". So, if you haven't already, write the library yourself and make it available to the general public.

    Dave Rooney
    Mayford Technologies

  11. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 8:33 AM by Thomas Mueller

    > Thomas, you sound like you have some good ideas.
    Thanks! So you agree it's too complicated?

    > Open Source
    This is a JSR. Even if I write a better library, it will not be included in the next JDK. However, JSR 310 could be included in Java 7. I'm scared.

  12. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 9:22 AM by Francois Ward

    Fluent interfaces. Great stuff, just NOT in "purist" languages like Java or C#. Keep those away (from the core libs), ugh. There's other languages that focus on those by design, and thats where they belong. Why is there such a need to always have 1 language that does everything every other languages, including specialized one, do...bleh.

  13. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 9:53 AM by Olivier Allouch

    Actually, what we really need are JSON-like structures so that we can do:
    Period p = new Period({years: 2, days: 5, minutes: 30});

    Sun, please, kill JavaFX and simplify Java.

  14. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 10:35 AM by Rob Elliot

    >> Open Source
    > This is a JSR.

    So what? Same principle applies; this JSR is firmly community driven. The lead developer on this one is doing so in his own time at his own expense, having previously written a successful open source date time API (Joda Time) of his own.

    It's been out there for two years, available for anyone to participate in. Still is. Quoting from jsr-310.dev.java.net/:

    "The main activity of the JSR will be on the public mailing list. If you are interested in observing or contributing to the discussion of this JSR, please feel free to join. Anyone can sign up to the dev mailing list.

    If you want to contribute suggestions, ideas or use cases on a one-off basis, the wiki may be for you. Especially feel free to add any requirements you have for the API to the requests page.

    If you want to raise bugs or feature requests on the code then you must become a java.net project member. To do this please request the special jsr>jsr-310.Observer role using the web form."

  15. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 3:09 PM by Stephen Cresswell

    Because those 2 classes were horribly, horribly misconceived. I agree there will be a learning curve, however if it's anything like the excellent Joda Time (written by JSR spec lead Stephen Colebourne) you'll be surprised how many of those classes end up being a godsend.

    java.util.Date - love the smell of deprication in the morning

  16. Back to top

    Re: 90 classes - simple to use?

    Oct 14, 2008 10:59 PM by Jonathan Allen

    Then at least allow both. Period probably already has a perfectly acceptable constructor, you just can't see it behind the builder's facade.

  17. Back to top

    Please help me

    Feb 17, 2009 4:09 AM by ahm alz

    Do any body has any jave program with at least 100 classes??
    please inform me, or send me the link to
    ahmad_mutah@yahoo.com

Educational Content

How HTML5 Web Sockets Interact With Proxy Servers

Peter Lubbers explains in this article how HTML5 Web Sockets interact with proxy servers, and what proxy configuration or updates are needed for the Web Sockets traffic to go through.

Rails in the Large: How Agility Allows Us to Build One Of the World's Biggest Rails Apps

Neal Ford shows what ThoughtWorks learned from scaling Rails development: infrastructure, testing, messaging, optimization, performance.

Stuart Halloway on Clojure and Functional Programming

Stuart Halloway discusses Clojure and functional programing on the JVM in depth, and touches on the uses of a number of other modern JVM languages including JRuby, Groovy, Scala and Haskell.

Oren Teich and Blake Mizerany on Heroku

Oren Teich and Blake Mizerany talk about the technology behind Heroku and the benefits of the new add-on system.

Security for the Services World

Chris Riley presents security issues threatening service based systems, examining security threats, presenting measures to reduce the risks, and mentioning available security frameworks.

Navigating The Rapids:Real-World Lessons in Adopting Agile

This talk investigates technical issues encountered when moving to an Agile process.

Codename "M": Language, Data, and Modeling, Oh My!

Don Box and Amanda Laucher present “M”, a declarative language for building data models, domain models or external DSLs. Don Box's demos show some of M’s features and latest changes of the language.

SOA Manifesto - 4 Months After

It is four months since the SOA manifesto was announced; InfoQ interviewed the original author’s to get insight into the motivations and the process behind the initiative.