Java SE 8 Date and Time(oracle.com)
oracle.com
Java SE 8 Date and Time
http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html
11 comments
The distribution of new Java versions is already decoupled from tzdata updates.
If you want to update your tzdata then you should use the tzupdater tool that is shipped with Java. This has been updated to support JSR-310. If you want to perform the updates then this is just a commandline tool and can be integrated into chef/puppet etc. as needed.
There was discussion during the development of JSR-310 about the inclusion of Java library methods to update a running JVM. There are a load of "not obvious to a developer" things that happen if you do this and it was decided the technical complexity and potential confusion outweighed the benefit of implementing it.
If you want to update your tzdata then you should use the tzupdater tool that is shipped with Java. This has been updated to support JSR-310. If you want to perform the updates then this is just a commandline tool and can be integrated into chef/puppet etc. as needed.
There was discussion during the development of JSR-310 about the inclusion of Java library methods to update a running JVM. There are a load of "not obvious to a developer" things that happen if you do this and it was decided the technical complexity and potential confusion outweighed the benefit of implementing it.
That's what I was referring to, though, as being operationally expensive. I need to ensure we're using up-to-date tzdata, but there could be multiple different runtimes running on hosts in locations I'm not aware of.
All I really wanted to say is that I want to be able to do a file drop of all of the binary data in a well-known location on all hosts and have all of the relevant languages / runtimes point to those files without running any additional tools, etc. Complexity starts multiplying once you add these external processes because of additional failure modes -- e.g., someone can run the tool manually and make things out of sync, no tools to monitor that things do stay in sync, handling backout of bad deployed data, installing a new not-yet-updated JRE version to a machine.
All I really wanted to say is that I want to be able to do a file drop of all of the binary data in a well-known location on all hosts and have all of the relevant languages / runtimes point to those files without running any additional tools, etc. Complexity starts multiplying once you add these external processes because of additional failure modes -- e.g., someone can run the tool manually and make things out of sync, no tools to monitor that things do stay in sync, handling backout of bad deployed data, installing a new not-yet-updated JRE version to a machine.
If Java Date was so broken before this, what have businesses been using the past few years? The article mentioned Joda-Date, but I'm curious if companies have used other solutions, or even built in-house solutions.
The joda libraries are the de-facto standard. I have seen custom solutions but usually those are for lower than millisecond resolution.
Actually it looks like Java 8 will improve on Joda-Time, its far from perfect.
For most applications we build, if time is relevant for more than just incidental functionality, we will typically use Joda-Time. For simply incidental functionality (e.g., a few UI elements displaying the time), we'll use the standard API.
I've not seen any home-brew date APIs outside of a few bite-size pieces of functionality. For instance, we have one custom utility that takes two times and a granularity level to render a human-readable rendering such as "2 hours, 13 minutes ago."
I've not seen any home-brew date APIs outside of a few bite-size pieces of functionality. For instance, we have one custom utility that takes two times and a granularity level to render a human-readable rendering such as "2 hours, 13 minutes ago."
A lot of people still use the built in Java stuff, they just don't enjoy it. Especially since a lot of code predates the existence of alternatives.
Most people use the Jodatime library. JSR-310 is an extension of Stephen Colebourne's work on that library.
Obviously there are some people who use java.util.Date, but it is a real pain in the neck to use and is very commonly complained about.
Obviously there are some people who use java.util.Date, but it is a real pain in the neck to use and is very commonly complained about.
The ICU Java libraries, though annoying to use, provide interoperability with ICU C libraries. ICU has the only correct implementation of time zone support for C that I have found. Though it's been a while since I researched the issue, I think ICU did something with time zones better than Joda Time, also.
We use a mix of the built-in java dates and joda, depending on how old the code is.
We have our own time library for some domain specific time code, which internally uses joda to handle dates.
We have our own time library for some domain specific time code, which internally uses joda to handle dates.
Good, but we expect much more from a major java release (i know that there are also some other improvements, but not too much).
I would even welcome an applet come-back (with some fresh ideas and some strong answers for the browser security related issues, keeping the old good java stack, not just the name like in case of JavaFX)
> Good, but we expect much more from a major java release (i know that there are also some other improvements, but not too much).
If the introduction of lambdas and streams is not enough for you, nothing will be.
If the introduction of lambdas and streams is not enough for you, nothing will be.
As justingregoryuk mentioned, i am thinking more on java as the platform. Why they (Oracle) don't come out with some innovation in this field? There are endless possibilities and they are sleeping.
Yes, they should push the platform not the language. There is still a very big potential in java. I am thinking about something like java se on ios. Or a new mobile platform based on java se. Or even better: a platform with html user interface and everything other java se. Firefox made it on javascript.
There are projects that do something along the line of both of your suggestions. For iOS, there's a project called RoboVM. (it's still claimed to be alpha, but the game engine LibGDX uses it to deploy to iOS). For web, there's GWT, which allows you to develop web apps in Java and it compiles to HTML/CSS/JS (or something along that line, though I hear it's verbose. LibGDX/PlayN use it to deploy to the browser though)
RoboVM is very promising. I bookmarked it some time ago, but unfortunately i don't see any progress since then. For example there are still no any documentation.
the answer to applet security problems is HTML5
"Time zones, which disambiguate the contexts of different observers, are put to one side here; you should use these local classes when you don’t need that context. A desktop JavaFX application might be one of those times."
WAT. Even if you assume that your user has exactly one TZ, how does this work with DST / summer time?
WAT. Even if you assume that your user has exactly one TZ, how does this work with DST / summer time?
Agreed, it's unclear from these examples if time-zone-less local times don't know about dst rules, or if they are backed by the user's timezone under the hood. Either way, calling DateTimes without timezone data LocalTime seems like a terrible idea, as "local" time is a very overloaded term.
It's often necessary in calendaring to describe a date time not as a point in time, but as a user-relative point in time (think holidays or birthdays). Android has support for "all day" dates in it's Time class, which is a step forward, but doesn't handle things like an alarm that should wake a traveller up at 6am tomorrow regardless of what time zone they have flown to. It's not clear that this new LocalTime is going to be a sufficient container for these, what the iCal RFC calls "floating times".
It's often necessary in calendaring to describe a date time not as a point in time, but as a user-relative point in time (think holidays or birthdays). Android has support for "all day" dates in it's Time class, which is a step forward, but doesn't handle things like an alarm that should wake a traveller up at 6am tomorrow regardless of what time zone they have flown to. It's not clear that this new LocalTime is going to be a sufficient container for these, what the iCal RFC calls "floating times".
Hi - just to be clear up front I co-authored the article. Thanks for raising this very valid point of confusion.
Let's address the issues one at a time.
1) What's the point in Local?
The goal is to give people the option to ignore the complexity involved with time zone rules. People are intuitively familiar with what these things mean. If you have a calendar on your wall above your desk: that's a LocalDate. If you have a clock on the wall: that's LocalTime. With respect to how they work in the presence of DST, they will automatically change time. For many use cases LocalDate and LocalTime is entirely suitable and people shouldn't be forced to put up with the unbearable complexity of timezones when they don't need to.
2) Why are they called Local?
As I mentioned above they represent the perspective of a clock on your wall or a calendar on your desk. They are local in this sense. I appreciate that these things might be a bit weird when you first get used to them and there was some discussion about renaming the classes during development. It was concluded that there were no better class names at the time. Furthermore if you looks at ISO 8601 [0] which is the most relevant standard to this API the same concept is also referred to as Local, Jodatime also uses the term Local.
3) Birthdays, Holidays and relative points in time
If you want to handle something like a birthday then there is a "MonthDay" class in JSR-310 which is designed for this exact purpose. It is a composite class of a month and a day and has an API consistent with the other classes in 310. If you want to handle 'relative' points in time then you might want to consider using the Duration or Period classes.
Hope that helps!
[0] http://en.wikipedia.org/wiki/ISO_8601
Let's address the issues one at a time.
1) What's the point in Local?
The goal is to give people the option to ignore the complexity involved with time zone rules. People are intuitively familiar with what these things mean. If you have a calendar on your wall above your desk: that's a LocalDate. If you have a clock on the wall: that's LocalTime. With respect to how they work in the presence of DST, they will automatically change time. For many use cases LocalDate and LocalTime is entirely suitable and people shouldn't be forced to put up with the unbearable complexity of timezones when they don't need to.
2) Why are they called Local?
As I mentioned above they represent the perspective of a clock on your wall or a calendar on your desk. They are local in this sense. I appreciate that these things might be a bit weird when you first get used to them and there was some discussion about renaming the classes during development. It was concluded that there were no better class names at the time. Furthermore if you looks at ISO 8601 [0] which is the most relevant standard to this API the same concept is also referred to as Local, Jodatime also uses the term Local.
3) Birthdays, Holidays and relative points in time
If you want to handle something like a birthday then there is a "MonthDay" class in JSR-310 which is designed for this exact purpose. It is a composite class of a month and a day and has an API consistent with the other classes in 310. If you want to handle 'relative' points in time then you might want to consider using the Duration or Period classes.
Hope that helps!
[0] http://en.wikipedia.org/wiki/ISO_8601
Thanks, that does help.
RFC 2445 refers to those date times at "floating", which I always preferred, since "local" is overloaded and makes it difficult to talk about:
http://www.ietf.org/rfc/rfc2445.txt
"floating" is a weird term, and I hate making words up, but at least it doesn't get confused in conversation with a time-zone-decorated timestamp that just happens to be in the user's local timezone.
But as long as it's possible to do what we need, which is sounds like it is, then that's what matters.
Thanks for the writeup.
EDIT: Regarding "Birthdays, Holidays and relative points in time",
MonthDay is not sufficient to describe all of the types of "floating" times, the canonical example given in RFC 2445 is of a user who wishes to appear unavailable at lunch every day, regardless of what time zone they are in. That's a more granular resolution than a day, but it's the same concept: an arbitrary precision, time-zone-less date that has no equivalent UTC start time until it is "observed".
RFC 2445 refers to those date times at "floating", which I always preferred, since "local" is overloaded and makes it difficult to talk about:
http://www.ietf.org/rfc/rfc2445.txt
"floating" is a weird term, and I hate making words up, but at least it doesn't get confused in conversation with a time-zone-decorated timestamp that just happens to be in the user's local timezone.
But as long as it's possible to do what we need, which is sounds like it is, then that's what matters.
Thanks for the writeup.
EDIT: Regarding "Birthdays, Holidays and relative points in time",
MonthDay is not sufficient to describe all of the types of "floating" times, the canonical example given in RFC 2445 is of a user who wishes to appear unavailable at lunch every day, regardless of what time zone they are in. That's a more granular resolution than a day, but it's the same concept: an arbitrary precision, time-zone-less date that has no equivalent UTC start time until it is "observed".
[deleted]
The Local* classes are immutable and do not store a time zone internally. So for instance, you can use LocalDate as a floating date to represent things like a birth date.
They're similar to Joda's Local* classes but the API has been cleaned up and vastly improved. Gone are all of those ugly constructors. They've been replaced by elegant static factory methods:
LocalDate.now(newYorkZoneId)
LocalDate.of(2013, Month.JANUARY, 1)
They're similar to Joda's Local* classes but the API has been cleaned up and vastly improved. Gone are all of those ugly constructors. They've been replaced by elegant static factory methods:
LocalDate.now(newYorkZoneId)
LocalDate.of(2013, Month.JANUARY, 1)
For those anticipating upgrading to Java 8 but would like to start using the new API now with JDK7, you might want to look at using the threeten backport so you can transition to the new Java 8 date API easily in the future.
http://www.threeten.org/
https://github.com/ThreeTen/threetenbp
http://www.threeten.org/
https://github.com/ThreeTen/threetenbp
java.util.Date wasn't broken per se, since people have been using it since Java first came out. It's just not pleasant to work with, the naming conventions are wrong, it's short-sighted in terms of international dates, etc. Classic example of what's wrong with the old methods - the dates are 0-indexed.
Here is one example of why I think Date is broken:
For quite awhile (maybe still?) calling `new Date()` made a synchronized call to a static method to try and figure out the default timezone. That created nasty lock contention in multithreaded code, nuking performance. Of course there is no way to create a new Date with a particular time zone. The other option was using the Calendar class since you could pass in a time zone, but a Calendar takes ~20 times more memory and is slow as hell to create. This meant you couldn't do something as simple as creating new Date classes with reasonable performance.
For quite awhile (maybe still?) calling `new Date()` made a synchronized call to a static method to try and figure out the default timezone. That created nasty lock contention in multithreaded code, nuking performance. Of course there is no way to create a new Date with a particular time zone. The other option was using the Calendar class since you could pass in a time zone, but a Calendar takes ~20 times more memory and is slow as hell to create. This meant you couldn't do something as simple as creating new Date classes with reasonable performance.
The months and days of week are 0-indexed. The dates of month are 1-indexed. Same as javascriopt. You always have to be careful with this API, but it helps to remember that they return an index in an array for the items that have a name in English (“January” and “Sunday”).
I've recently been sitting down and relearning Java. Not good enough to be idiomatic in the language, but whatever. One of the first things I banged into was the unbelievably bad date/time libraries that are built in. After banging my head for a couple hours trying to figure out the magical combination of classes I needed to assemble to get a date formatter to work, I just ended up rolling my own in half an hour.
I'm frequently surprised at the really rough and inconvenient bits in Java. Weird inconsistencies in the libraries, or not having a really convenient set of file read/write methods without having to cobble together bits and pieces of an I/O system to get a directory listing or read in a file or whatever, or how variable performance is between two similar looking pieces of code (if you haven't done lots of benchmarking on Java standard library containers, I urge you to do it, and make careful selection of containers based on that, it's frequently surprising how different otherwise identical looking code runs).
Considering there are what, 3 complete GUI toolkits built in, why isn't there a built in CSV parsing library, or a "read file to string" static method somewhere? Why do I have to put so much effort into basic tasks? It's such a weird and uneven and sloppy feeling thing.
There's all these weird aggregated different ways to do the same thing, but each built to fix some problem with some older solution, but the older broken ways were never really deprecated out for compatibility. Unless you run across some guide that says explicitly "use this instead of this because of <reasons>" you might never know the newer version exists. Yet the new releases includes so much compatibility breaking new syntax changes that it doesn't practically matter.
There's bits and pieces of related but complete solutions piled all over the library as well. e.g. Regex bits are in String, java.util.regex.* (Pattern and Matcher) and probably elsewhere...and don't get me started if you're moving back and forth between arrays and the various containers that make arrays more usable, and then all the utilities to help with that which are scattered all over the place. I spend half my time writing code to abstract all that nonsense away so I can write the main code logic in peace.
And then over the years the concepts about how to design an API have changed or something, because you can feel different stylistic concepts in different places. Here you instantiate an object, then set it up, then build another object of this type to catch the results and do some other magic. Here you instantiate the object with all the important bits and manipulate the object with local methods. It's like each class requires it's own style guide. I can understand that with 3rd party work, but it doesn't make sense with the batteries that come with the language to be so uneven.
It was probably 10 years ago that I last tried Java, and it sucked back then, with all the verbosity etc. But with modern IDE support I actually kind of like the flow and style of it to some extent. It's a beautifully simple syntax to use at its core. But then again I don't care about all the FactoryFactory nonsense. And I'm avoiding lots of the new stuff that doesn't really fit into the language.
I've actually started to become convinced that it's getting to the point that Java 10 or whatever should be a single minded house cleaning. Jettison all the broken old shit, clean up the style and usage, build decent syntax into the language for doing common tasks so the coder doesn't have to boilerplate themselves to death. Take 5 years to do it, the enterprise will survive that long.
edit I wonder if the idea of an "API editor" to vet the interfaces for consistency and style in these large standard libraries makes sense?
I'm frequently surprised at the really rough and inconvenient bits in Java. Weird inconsistencies in the libraries, or not having a really convenient set of file read/write methods without having to cobble together bits and pieces of an I/O system to get a directory listing or read in a file or whatever, or how variable performance is between two similar looking pieces of code (if you haven't done lots of benchmarking on Java standard library containers, I urge you to do it, and make careful selection of containers based on that, it's frequently surprising how different otherwise identical looking code runs).
Considering there are what, 3 complete GUI toolkits built in, why isn't there a built in CSV parsing library, or a "read file to string" static method somewhere? Why do I have to put so much effort into basic tasks? It's such a weird and uneven and sloppy feeling thing.
There's all these weird aggregated different ways to do the same thing, but each built to fix some problem with some older solution, but the older broken ways were never really deprecated out for compatibility. Unless you run across some guide that says explicitly "use this instead of this because of <reasons>" you might never know the newer version exists. Yet the new releases includes so much compatibility breaking new syntax changes that it doesn't practically matter.
There's bits and pieces of related but complete solutions piled all over the library as well. e.g. Regex bits are in String, java.util.regex.* (Pattern and Matcher) and probably elsewhere...and don't get me started if you're moving back and forth between arrays and the various containers that make arrays more usable, and then all the utilities to help with that which are scattered all over the place. I spend half my time writing code to abstract all that nonsense away so I can write the main code logic in peace.
And then over the years the concepts about how to design an API have changed or something, because you can feel different stylistic concepts in different places. Here you instantiate an object, then set it up, then build another object of this type to catch the results and do some other magic. Here you instantiate the object with all the important bits and manipulate the object with local methods. It's like each class requires it's own style guide. I can understand that with 3rd party work, but it doesn't make sense with the batteries that come with the language to be so uneven.
It was probably 10 years ago that I last tried Java, and it sucked back then, with all the verbosity etc. But with modern IDE support I actually kind of like the flow and style of it to some extent. It's a beautifully simple syntax to use at its core. But then again I don't care about all the FactoryFactory nonsense. And I'm avoiding lots of the new stuff that doesn't really fit into the language.
I've actually started to become convinced that it's getting to the point that Java 10 or whatever should be a single minded house cleaning. Jettison all the broken old shit, clean up the style and usage, build decent syntax into the language for doing common tasks so the coder doesn't have to boilerplate themselves to death. Take 5 years to do it, the enterprise will survive that long.
edit I wonder if the idea of an "API editor" to vet the interfaces for consistency and style in these large standard libraries makes sense?
The only way to think about Java and not go insane is to forget about pretty much the entire built-in standard library and instead go use the extremely solid 3rd party libraries. If I don't have JodaTime, Apache Commons and Google Guava on my classpath, I feel like my hands are tied.
I think that's a bit strong. There are bits of the standard library that are fine - collections, concurrency, and anything else designed by Doug Lea. I even get on fine with IO and most of networking. Sure, Guava adds a lot of really nice stuff to collections, but it adds rather than replaces.
Then there are bits which should be avoided at all costs. Date and time is one. All the GUI libraries are another. HTTP via URLConnection isn't terrible, but people mostly use Apache HttpClient instead. NIO is a mixed bag, with some really good bits, and some complexity whose necessity escapes me (particularly since it can be hidden by XNIO without losing anything).
It is a real shame that there is this patchiness. I would love to claim that all the rough code is from the pre-1.2 era, but i would be lying. Particularly if you look beyond the JDK and into the enterprise libraries, there have been some real shitshows given official imprimatur (i remember Java Advanced Imaging being particularly horrifying).
Then there are bits which should be avoided at all costs. Date and time is one. All the GUI libraries are another. HTTP via URLConnection isn't terrible, but people mostly use Apache HttpClient instead. NIO is a mixed bag, with some really good bits, and some complexity whose necessity escapes me (particularly since it can be hidden by XNIO without losing anything).
It is a real shame that there is this patchiness. I would love to claim that all the rough code is from the pre-1.2 era, but i would be lying. Particularly if you look beyond the JDK and into the enterprise libraries, there have been some real shitshows given official imprimatur (i remember Java Advanced Imaging being particularly horrifying).
JAI was real bad.. JMF (Java Media Framework) was another one, which for a while had the unfortunate distinction of being the only reliable way of playing video on top of being poorly documented and turning into abandonware.
Funny how in languages like python or clojure, the bazaar library eco system can be a fuzzy moving target daunting to control, while Java stdlib is on the other side of things, but too far, Guava, Apache Commons, Joda could have been made standard but it's not.
That's one of the main reasons I enjoy programming in C#/.NET. The fact that there are, as far as I'm concerned, a solid set of de facto libraries without having to hunt around for third-party ones somehow makes me feel warm and fuzzy.
With the exception of JodaTime, which is quite well designed, most of the third party libraries you mention or absolute shit. Apache Commons in particular is worse than ammateur hour work.
And while the quality of the standard SDK varies, most of it is very good, and there are stuff that's solid gold in there, like Nio and Concurrency libs.
And while the quality of the standard SDK varies, most of it is very good, and there are stuff that's solid gold in there, like Nio and Concurrency libs.
I've had good luck with Apache Commons. What specifically do you find objectionable about it?
Also, you really shouldn't just drop "x sucks" into a conversation without backing it up with something reasonable. Or was this a well-crafted troll comment?
Also, you really shouldn't just drop "x sucks" into a conversation without backing it up with something reasonable. Or was this a well-crafted troll comment?
Well, regarding the "x sucks", I was responding to someone who advised people to "forget about pretty much the entire built-in standard library" lest you want to go insane.
As for the Apache Commons, well where to start? It's been several years since I last dealed with them, on my Java days, but there were lots of issues.
From the general overboard AbstractFactoryProxyFactorytis and overall OO fails (real example: DoubleListIteratorListIterator), to useless utility classes that replicate already existing SDK capabilities, to the lack of generics support for the collections (for a looooong time, don't know if they fixed this now) -- oh, and them not being compatible with Java collection interfaces either --, to lack of thread safety, to string output libraries blisfully unaware of the existance of encodings, and a whole lot more besides.
As for the Apache Commons, well where to start? It's been several years since I last dealed with them, on my Java days, but there were lots of issues.
From the general overboard AbstractFactoryProxyFactorytis and overall OO fails (real example: DoubleListIteratorListIterator), to useless utility classes that replicate already existing SDK capabilities, to the lack of generics support for the collections (for a looooong time, don't know if they fixed this now) -- oh, and them not being compatible with Java collection interfaces either --, to lack of thread safety, to string output libraries blisfully unaware of the existance of encodings, and a whole lot more besides.
>After banging my head for a couple hours trying to figure out the magical combination of classes I needed to assemble to get a date formatter to work, I just ended up rolling my own in half an hour.
It's really not that difficult to assemble the combination of classes to get a formatter. There are problems with the API, but that's not one of them.
Plus, your hand rolled case probably misses hundrends of edge cases (I'm not exagerrating, date and time is one of the most difficult things to get right).
It's really not that difficult to assemble the combination of classes to get a formatter. There are problems with the API, but that's not one of them.
Plus, your hand rolled case probably misses hundrends of edge cases (I'm not exagerrating, date and time is one of the most difficult things to get right).
It turns out certain subsets of things you need to do with Dates are pretty easy. In my case all I needed was to convert a date format to another. All I wanted was something like
The end result is that we're all poorer for it.
Date thing = new Date(someStringWithaDate,"MMM dd, yyyy");
String newDateThing = thing.convertDateFormat("yyyy-mm-dd");
Date thing = new Date(someStringWithaDate,"MMM dd, yyyy");
Date newDateThing = thing.convertDateFormat("yyyy-mm-dd");
String someStringWithaDateButFormattedLikeIWant = newDateThing.toString();
String.replaceAll("([A-Z]{3}) (\d{2}), (\d{4})","$3-$2-$1");
The end result is that we're all poorer for it.
I think you are overlooking the fact that perhaps there was an easier and/or more idiomatic way to convert from one format to another, but that you missed out on how to do it with the (admittingly poor) standard date/time libraries since you haven't had to solve this particular problem in Java before. You probably just want something like:
DateFormat format1 = new SimpleDateFormat("MMM dd, yyyy");
DateFormat format2 = new SimpleDateFormat("yyy-mm-dd");
String originalDateString = ...;
String newDateString = format2.format(format1.parse(originalDateString));
True, it's been so long since I Java'd at all, that I simply don't remember the idiomatic ways to do things. And those ways have probably changed quite a bit in the intervening years.
Still it seems conceptually weird that the idea of a DateFormat object can be a thing, when it's just a String with the magic Format language.
Parsing or formatting (the verbs) seem more like actions to be taken on a Date itself. It seems much tidyier to me to just keep all that contextually in the Date class.
Still it seems conceptually weird that the idea of a DateFormat object can be a thing, when it's just a String with the magic Format language.
Parsing or formatting (the verbs) seem more like actions to be taken on a Date itself. It seems much tidyier to me to just keep all that contextually in the Date class.
From a theoretical perspective, date formatting is a behavior that can be accomplished in a number of different ways. While the pre-Java 8 API only provides SimpleDateFormat, JodaTime provides a similar class and a slew of formatters based upon ISO8601 that don't use patterns at all.
From a practical standpoint, SimpleDateFormat and its analogues don't operate directly on the format string you supply, but instead compile it into a form that is easier to process. If Date.format was the only way to format a date, then the format pattern would have to be recompiled on every call (or else cached, which would affect thread safety).
Now, String.split exists, despite having to recompile the regular expression every time it is called (except for certain optimized cases), so presumably Date.format could also exist, but DateFormat would still be preferable for many cases.
From a practical standpoint, SimpleDateFormat and its analogues don't operate directly on the format string you supply, but instead compile it into a form that is easier to process. If Date.format was the only way to format a date, then the format pattern would have to be recompiled on every call (or else cached, which would affect thread safety).
Now, String.split exists, despite having to recompile the regular expression every time it is called (except for certain optimized cases), so presumably Date.format could also exist, but DateFormat would still be preferable for many cases.
A quick google would have found:
new SimpleDateFormat("HH MM YYYY").format(new Date());
new SimpleDateFormat("HH MM YYYY").parse("17 02 2014");
Well geez, there you go. My google fu obviously failed me, I definitely did not come across this yet another Date Formatting library in the Java Standard Library.
Why isn't all this garbage just bundled into the Date class? It seems to me that among the many things somebody might want to do on a date, converting the String representation might be one of them.
okay here's what I'm talking about. From the API docs on Date
Okay, so what's a DateFormat?
Wait there's a DateFormatter, that sounds promising, it's all verby sounding.
I did eventually figure it out. But it was so inelegant and stupid I felt ashamed to have it in my code. If I had read one more line in the DateFormatter doc I suppose I could have found SimpleDateFormat, but the bizarre complexity about converting formats was already so mind bendingly dumb.
This is stupid and obtuse design, overly parsing the problem and unnecessarily separating what should be connected pieces of the puzzle.
Solution (needs revision, but this would be a useful point to start a discussion):
Classes
Date - a representation of a specific date and time down to millionths of a second resolution
methods:
Duration - an representation of a time Duration (6 days, 7 minutes, 14 second), and since all time intervals are durations, that's it.
Methods:
Why isn't all this garbage just bundled into the Date class? It seems to me that among the many things somebody might want to do on a date, converting the String representation might be one of them.
okay here's what I'm talking about. From the API docs on Date
toGMTString() - *Deprecated.* As of JDK version 1.1, replaced by DateFormat.format(Date date), using a GMT TimeZone.
toLocaleString() - *Deprecated.* As of JDK version 1.1, replaced by DateFormat.format(Date date).
toString() - Converts this Date object to a String of the form: dow mon dd hh:mm:ss zzz yyyy
Okay, so what's a DateFormat?
DateFormat is an abstract class for date/time formatting subclasses which formats and parses dates or time in a language-independent manner.
Wait there's a DateFormatter, that sounds promising, it's all verby sounding.
DateFormatter is an InternationalFormatter that does its formatting by way of an instance of java.text.DateFormat.
I did eventually figure it out. But it was so inelegant and stupid I felt ashamed to have it in my code. If I had read one more line in the DateFormatter doc I suppose I could have found SimpleDateFormat, but the bizarre complexity about converting formats was already so mind bendingly dumb.
This is stupid and obtuse design, overly parsing the problem and unnecessarily separating what should be connected pieces of the puzzle.
Solution (needs revision, but this would be a useful point to start a discussion):
Classes
Date - a representation of a specific date and time down to millionths of a second resolution
methods:
add, sub Dates - returns Duration
add,sub Duration, returns Dates
one of the constructors takes a String that ostensibly contains a Date of some sort, and a format String to parse it, throws exception if the date isn't valid
setOutPutFormat - takes a Format string and the next call toString() emits on that format.
all the get, set hour minute day year methods so you can pick it apart change pieces as you want
setOutPutCalendar - changes the Date to whatever recognized calendar system (Chinese, Arabic, Hebrew, etc.), setOutPutFormat is context aware of this
all the timezone stuff
after and before
get/set 2 digit year
Date comparison methods like isBefore(Date) to see if another Date object is before or after this one
Duration - an representation of a time Duration (6 days, 7 minutes, 14 second), and since all time intervals are durations, that's it.
Methods:
Constructor can be an ISO 8601 String for Duration or two Date objects representing the beginning and end of a duration. Since Date objects should have their own timezone and locals, the magic black box of this class should figure out the duration for me. It's not my problem to sort this out. If the begin and end dates produce a negative duration that's cool because now I have a countdown.
Duration comparison methods, like isWithin(Duration) to check if another duration object is within this one or isWithin(Date) to see if a Date is within the duration or isLongerthan(Duration)
Duration math like add/subtract other durations from the begin and end of the Duration
Most of what you want sounds like DateTime and TimeSpan from .net.
However Joda does a lot more, like taking into account the various historical, political changes in time zone, and the distinction between a duration between two human-understandable semantic times, versus a duration as a fixed span of time.
However Joda does a lot more, like taking into account the various historical, political changes in time zone, and the distinction between a duration between two human-understandable semantic times, versus a duration as a fixed span of time.
I'm probably looking at the issue too simply, but shouldn't all that be abstracted away into the library, with maybe some notes on particularly weird cases?
I'm also not sure I understand the distinction between the two durations, if I set a startDate object up on the Islamic Tabular Fatimid calendar and say it's year 14 and endDate is some pre-reformation Julian calendar and say it's year 231, shouldn't the Duration class be able to figure out a fixed span of time from that? I really could care less how it does it, just that the right number of years, months and days fall out of it. Or if I just want to create the object with some defined span, they're the same thing.
I'm also not sure I understand the distinction between the two durations, if I set a startDate object up on the Islamic Tabular Fatimid calendar and say it's year 14 and endDate is some pre-reformation Julian calendar and say it's year 231, shouldn't the Duration class be able to figure out a fixed span of time from that? I really could care less how it does it, just that the right number of years, months and days fall out of it. Or if I just want to create the object with some defined span, they're the same thing.
Given a date, how do you obtain a new date equal to the same month and day of month in the following year?
You can't do that consistently with a duration measured in milliseconds or nanoseconds. Instead, you need a more abstract representation of time, something akin to "increment only the year field of a date".
That's what Periods are for.
You can't do that consistently with a duration measured in milliseconds or nanoseconds. Instead, you need a more abstract representation of time, something akin to "increment only the year field of a date".
That's what Periods are for.
Regarding date and time stuff, everyone appears to use Joda-Time: http://www.joda.org/joda-time/
If you want inconsistent, .Net framework's collections and HTTP stuff was the worst for years. They added to the former and wrapped the latter but you still fall over crimes. Java collections and Servlet API are pretty good really in comparison.
It's not terrible really. Anything on that scale is inconsistent: python, ruby, .Net, C++.
The hard bit is learning where stuff is hidden. I'm currently doing that with Objective-C.
If you want inconsistent, .Net framework's collections and HTTP stuff was the worst for years. They added to the former and wrapped the latter but you still fall over crimes. Java collections and Servlet API are pretty good really in comparison.
It's not terrible really. Anything on that scale is inconsistent: python, ruby, .Net, C++.
The hard bit is learning where stuff is hidden. I'm currently doing that with Objective-C.
> Anything on that scale is inconsistent: python, ruby, .Net, C++.
Well, I wonder if this is necessarily inevitable. The Oxford English Dictionary is probably as large and complex as any of the above, but is remarkably consistent in style and tone. I'm a firm believer that good design extends to code (and coders are sadly not very good designers in general).
Well, I wonder if this is necessarily inevitable. The Oxford English Dictionary is probably as large and complex as any of the above, but is remarkably consistent in style and tone. I'm a firm believer that good design extends to code (and coders are sadly not very good designers in general).
The difference between a dictionary and a standard library is you can change entries in a new dictionary as much as you like and no-one will complain that their book no longer compiles :)
It would be nice if a programming language came along that designed all features right from the start, so no features ever needed to be deprecated or redesigned. Unfortunately I have yet to find a language that is all things to all people, even after several versions; designing a language perfectly from scratch might not even be possible.
It would be nice if a programming language came along that designed all features right from the start, so no features ever needed to be deprecated or redesigned. Unfortunately I have yet to find a language that is all things to all people, even after several versions; designing a language perfectly from scratch might not even be possible.
Yeah I agree. But perhaps a tick-tock version release schedule could work well for this. Odd number versions fix bugs, and even ones introduce new things, deprecate old things, fix bad syntax etc. I know it's sort of being tried with Python right now, but it's sort of this monumental this or that (with that not being clearly better) that doesn't seem to be working. The way the Perl community is back porting perl 6 bits into 5 does.
Keeping the even releases well scoped would ease the pain of transitioning. Maybe ensure some guaranteed level of support for 12-24 months a la Ubuntu and we might have a good model for language development.
Keeping the even releases well scoped would ease the pain of transitioning. Maybe ensure some guaranteed level of support for 12-24 months a la Ubuntu and we might have a good model for language development.
Well, deprecating the language every 12 months would sure be good for developers on support contracts. If we could make it so most new software needs you to have the latest version of the language/vm/runtime, and our software needs an older version with deprecated features, customers would have to keep paying for upgrades whether we were adding new features or not.
For the end users, people who don't get paid to do maintenance etc it might not be so good.
For the end users, people who don't get paid to do maintenance etc it might not be so good.
There's not really any reason why software couldn't still be maintained/written in an older version of the language, and have older VM/runtimes sitting around to deal with that. It's not like I can run Java 7 code on a Java 6 VM.
Hell, isn't that de rigueur anyways these days? We're already dealing with this problem, except the language itself is getting worse.
Hell, isn't that de rigueur anyways these days? We're already dealing with this problem, except the language itself is getting worse.
Java is actually very good at backwards compatibility - sometimes IMHO going annoyingly far, like type erasure on collections. Java 6 bytecode will run on the Java 7 JVM, and Java 6 source will compile with the Java 7 JDK, modulo one or two incompatibilities [1]. Oracle 'highly recommend' you uninstall old versions [2].
On the other hand, when I install the Google App Engine Python SDK on Ubuntu it causes my hex editor to stop working. And I use some Ruby software where getting it working meant a nasty fight with xcode and rvm, which left me fearful that if I ever upgrade, reinstall or switch computers I'll never get it working again :) admittedly my knowledge of ruby is pretty weak.
[1] http://www.oracle.com/technetwork/java/javase/compatibility-... [2] http://www.java.com/en/download/faq/remove_olderversions.xml
On the other hand, when I install the Google App Engine Python SDK on Ubuntu it causes my hex editor to stop working. And I use some Ruby software where getting it working meant a nasty fight with xcode and rvm, which left me fearful that if I ever upgrade, reinstall or switch computers I'll never get it working again :) admittedly my knowledge of ruby is pretty weak.
[1] http://www.oracle.com/technetwork/java/javase/compatibility-... [2] http://www.java.com/en/download/faq/remove_olderversions.xml
So, are you using python3?
Agreed. It definitely shouldn't be inevitable.
I left Go off that list precisely for that reason.
I left Go off that list precisely for that reason.
I agree with you. yeah, there are some new APIs in nio Files that you weren't aware of. But now you have to know go to Files for the "Good API" instead of the old "File" API. Bow to the Gods of backwards compatibility!
The JDBC API is still beyond horrible (is there a decent 3rd party SQL API?). Checked Exceptions still survive. String still lacks many basic features.... and sadly as others have pointed out to get usable APIs you need Apache Commons.
I agree, Oracle needs to do some house cleaning. Some times it's ok to break things. Don't do it too often, but once every 10 years seems ok to me!
The JDBC API is still beyond horrible (is there a decent 3rd party SQL API?). Checked Exceptions still survive. String still lacks many basic features.... and sadly as others have pointed out to get usable APIs you need Apache Commons.
I agree, Oracle needs to do some house cleaning. Some times it's ok to break things. Don't do it too often, but once every 10 years seems ok to me!
The Java standard API has a lot of inconsistencies, but it would break too much code to remove old stuff. A simpler first step would be much more aggressive use of @Deprecated. There are entire packages in the standard API that should be deprecated. Most Java IDE strongly discourage using deprecated code. More use of @Deprecated would encourage future Java code to use more modern APIs.
As for the reading file into a string, there is almost somethig like that: http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files...
There is a method for reading a file into a list of lines (it is strange that they didn't include a method to read the lines into a single string).
There is a method for reading a file into a list of lines (it is strange that they didn't include a method to read the lines into a single string).
In Java 7 you can use Files.readAllLines to read file to string, also there is a built-in CSV parsing library, it's called String.split() :)
String.split will work fine until you have data like this:
Sarah Jones,Paul Williams,"Smith, John",Fred Johnson
It's best to use a library for this like SuperCSV: http://supercsv.sourceforge.net
It's best to use a library for this like SuperCSV: http://supercsv.sourceforge.net
This. This is such a common problem, I added it to our formal code test. We supply an interface, a unit test and a rather broken CSV file and they have to make the test pass by adding the implementation.
22 people failed the test entirely, complaining about quotes and line ending inconsistency.
2 people wrote a proper state machine driven parser that didn't work.
1 person wrote a proper state machine driven parser that worked.
1 person imported commons-csv and wrapped stuff.
The last person got the job.
22 people failed the test entirely, complaining about quotes and line ending inconsistency.
2 people wrote a proper state machine driven parser that didn't work.
1 person wrote a proper state machine driven parser that worked.
1 person imported commons-csv and wrapped stuff.
The last person got the job.
2 people wrote a proper state machine driven parser that didn't work.
1 person wrote a proper state machine driven parser that worked.
You probably missed three really good candidates here.
You probably missed three really good candidates here.
We didn't really. They, respectively, didn't finish the entire test, over-engineered a few of the other questions and failed the comprehension test (we test the ability to understand requirements as well).
The thing is clearly marked "pragmatic solutions" rather than most interesting as well.
The thing is clearly marked "pragmatic solutions" rather than most interesting as well.
Sure, but if you've only got one position, you might as well go for the one with enough experience/wisdom to get it right.
>>1 person wrote a proper state machine driven parser that worked.
Look, the fact is, based on the replies below, this guy is probably better off working somewhere else.
Not to go off on this particular person, the preoccupation with "Library Knowledge(tm)" in the enterprise (so, Java) world has become an epidemic. I have seen libraries used for all the wrong reasons, pulling in great gobs of someone elses code to do a bloody string copy!
Damn, you are hiring coders. Let them fricken code, for God's sake.
Please, I know all of the counter arguments (I've been harangued by them for years), but I really think that there is a middle ground here. Some things are truly worth bringing into a project via library. Big things, things that are really hard things that you may not have the staff to handle. But if we are afraid to let coders code some stuff, even trivial stuff, then we have killed the one true joy that we had in the first place: coding!
One thing to remember about libraries is that they have bugs too! Just because someones got an apache page, doesn't mean that there are no bugs in there lurking. You WILL most probably need to understand the problem/solution well enough to use the library in the first place.
Gosh, rant off.
Look, the fact is, based on the replies below, this guy is probably better off working somewhere else.
Not to go off on this particular person, the preoccupation with "Library Knowledge(tm)" in the enterprise (so, Java) world has become an epidemic. I have seen libraries used for all the wrong reasons, pulling in great gobs of someone elses code to do a bloody string copy!
Damn, you are hiring coders. Let them fricken code, for God's sake.
Please, I know all of the counter arguments (I've been harangued by them for years), but I really think that there is a middle ground here. Some things are truly worth bringing into a project via library. Big things, things that are really hard things that you may not have the staff to handle. But if we are afraid to let coders code some stuff, even trivial stuff, then we have killed the one true joy that we had in the first place: coding!
One thing to remember about libraries is that they have bugs too! Just because someones got an apache page, doesn't mean that there are no bugs in there lurking. You WILL most probably need to understand the problem/solution well enough to use the library in the first place.
Gosh, rant off.
We pay people for robust solutions, not to write code. It's a whole lot more complicated than "just programming". In fact we'd rather they wrote less code and did more thinking.
Experienced engineers will trade off a COTS solution against build. Inexperienced engineers will machine 2000 M3x12 screws by hand.
Just because you're an engineer doesn't mean we want you to sit in front of a lathe/mill all day.
Libraries wouldn't exist if we didn't want to reuse work. With respect to more bugs in libraries, this is rarely the case for established products. In fact by writing our own code with similar intent will almost certainly incur more test effort, more odd edge cases and more $$$.
Final point: I wrote some code a few years ago in Java that spoke to .doc files, databases, a SOAP API and a service bus. It was (excluding blank lines and bracketed lines) 2900 lines of code with 850 unit tests. It handles over a million insurance contracts a year. This would have not been possible if I'd written ANY component myself.
I was paid to solve the problem, not write those libraries again.
Experienced engineers will trade off a COTS solution against build. Inexperienced engineers will machine 2000 M3x12 screws by hand.
Just because you're an engineer doesn't mean we want you to sit in front of a lathe/mill all day.
Libraries wouldn't exist if we didn't want to reuse work. With respect to more bugs in libraries, this is rarely the case for established products. In fact by writing our own code with similar intent will almost certainly incur more test effort, more odd edge cases and more $$$.
Final point: I wrote some code a few years ago in Java that spoke to .doc files, databases, a SOAP API and a service bus. It was (excluding blank lines and bracketed lines) 2900 lines of code with 850 unit tests. It handles over a million insurance contracts a year. This would have not been possible if I'd written ANY component myself.
I was paid to solve the problem, not write those libraries again.
In my mind the bigger issue is that something like CSV parsing is so common, and so old that it just should be part of every higher level language's standard library these days, as common as split() is. That way people learning the language learn that you just do it with the library and get on with it.
(I agree with the rest, anybody can more or less learn their way around a library with a little time, but learning to actually code well is a much more valuable skill and much more rare).
(I agree with the rest, anybody can more or less learn their way around a library with a little time, but learning to actually code well is a much more valuable skill and much more rare).
I thought for coding tests implementations are supposed to be done from scratch on. Or at least the guy who wrote the working parser should be on top of the list.
Not really. We want people to solve the problem, not invent something that needs maintenance. In some cases, from scratch is important, but for most it's not.
Sounds like you don't want competent people to challenge the rest.
No we don't want competent people showboating and pissing cash up the wall reinventing wheels that have a high maintenance cost because it's fun.
We hire engineers.
An analogy: would you hire the electrical engineer who knocks up an ASIC for every task or the one who designs in a COTS part for a predictable unit cost and manufacturing lead time?
We hire engineers.
An analogy: would you hire the electrical engineer who knocks up an ASIC for every task or the one who designs in a COTS part for a predictable unit cost and manufacturing lead time?
> Files.readAllLines
Geez, I think I've already reimplemented that half a dozen times. Of course it would be buried in the Files class and not one of the 30 dozen buffer reader whatever classes I have to piece together.
> String.split()
Yeah yeah, that's what all the Java books say ;)
Geez, I think I've already reimplemented that half a dozen times. Of course it would be buried in the Files class and not one of the 30 dozen buffer reader whatever classes I have to piece together.
> String.split()
Yeah yeah, that's what all the Java books say ;)
yeah right.....and what's the XML parsing library called? java.util.regex? And the SQL parameterized query library? string.format?
I wonder how hard it would be to port all of the python standard library to java?
Sort of have python.csv.reader, python.csv.DictReader, etc, which all conform as java-ish as possible to http://docs.python.org/release/2.7.3/library/csv.html
Sort of have python.csv.reader, python.csv.DictReader, etc, which all conform as java-ish as possible to http://docs.python.org/release/2.7.3/library/csv.html
The problem of course is that it would probably be some external library like the apache commons stuff and never get integrated into the main library.
And there's still all the old poorly thought out junk still crufting up the standard library.
And there's still all the old poorly thought out junk still crufting up the standard library.
20 years to finally get this right. TWENTY YEARS, MAN!
Java startup time will hopefully be fixed in Java 9. That also has been eagerly anticipated for quite some time.
http://mreinhold.org/blog/late-for-the-train
http://mreinhold.org/blog/late-for-the-train
I initially parsed this as suggesting that a JVM took 20 years to start up, and thought "Come on, man, with the right flags it's no more than 12 ...".
And it will take quite some time to actually get deployed anywhere. JRE 6 is enough for everything we need to run, right? So why update it? :(
19, you mean?
I used Java to calculate the time difference.
Thank you for brightening a miserable afternoon.
>> The new API avoids this issue by ensuring that all its core classes are immutable and represent well-defined values.
Is there any kind of talk of adding immutability to the core language? "final" keyword doesn't really cut it for objects and immutabililty by convention also is not easy to enforce on large teams.
Is there any kind of talk of adding immutability to the core language? "final" keyword doesn't really cut it for objects and immutabililty by convention also is not easy to enforce on large teams.
There has been a lot of discussion on this kind of thing. One of the proposals for value types is to have them be immutable.
As to what to do in the meantime - I would suggest that you use either findbugs' immutability detection or Graham Allen's Mutability Detector: https://github.com/MutabilityDetector/MutabilityDetector. Findbugs picks up an @Immutable annotation and checks whether this is the case, whilst Mutability Detector allows you to assert that classes are immutable as part of your unit tests.
I appreciate its not as good as language support, but it is better than relying on an unchecked convention.
As to what to do in the meantime - I would suggest that you use either findbugs' immutability detection or Graham Allen's Mutability Detector: https://github.com/MutabilityDetector/MutabilityDetector. Findbugs picks up an @Immutable annotation and checks whether this is the case, whilst Mutability Detector allows you to assert that classes are immutable as part of your unit tests.
I appreciate its not as good as language support, but it is better than relying on an unchecked convention.
[deleted]
[deleted]
The tzdata updates usually 10+ times a year and a company actually operating in most of those zones needs to have a straightforward way to push out updates not only across all production systems, but across all production languages. This usually makes solutions that "transpile" the binary data into native source or otherwise embed the data into resources somewhere much more operationally expensive. Native solutions (e.g., pytz in Python) that can be pointed to an directory to pick up the tzdata binary files are a good middle-ground, as it decouples the logic from the data.
Operationally, you need to be able to deploy the updates very quickly. Every year there are data updates that occur a few days before the DST change. If you have a lengthy dev/beta/prod rollout process to a very large number of machines, this can bite you. Just this week, Chile and Turkey are making changes, so prepare to update :)