12 ms·

Java SE 8 Date and Time

84 points by javinpaul 13y ago

beachwood23 13y ago
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.
- kasey_junk 13y ago
  The joda libraries are the de-facto standard. I have seen custom solutions but usually those are for lower than millisecond resolution.
  - greatsuccess 13y ago
    Actually it looks like Java 8 will improve on Joda-Time, its far from perfect.
- smackfu 13y 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.
- bhauer 13y ago
  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."
- gcv 13y ago
  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.
- rlmw 13y ago
  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.
- ajanuary 13y ago
  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.
moron4hire 13y ago
20 years to finally get this right. TWENTY YEARS, MAN!
- melling 13y ago
  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
  - twic 13y ago
    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 ...".
- viraptor 13y ago
  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? :(
- jfb 13y ago
  19, you mean?
  - moron4hire 13y ago
    I used Java to calculate the time difference.
    - billforsternz 13y ago
      Thank you for brightening a miserable afternoon.
bluedevil2k 13y ago
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.
- yonran 13y ago
  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”).
- mbell 13y ago
  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.
al2o3cr 13y ago
"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?
- kinofcain 13y ago
  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".
  - nogridbag 13y ago
    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)
  - rlmw 13y ago
    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 http://en.wikipedia.org/wiki/ISO_8601
fenesiistvan 13y ago
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)
- brazzy 13y ago
  > 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.
  - fenesiistvan 13y ago
    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.
- justingregoryuk 13y ago
  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.
  - FreezerburnV 13y ago
    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)
    - 13y ago
apaprocki 13y ago
Is there any talk in the Java world of decoupling the runtime from the tzdata distribution? AFAIK, it is still coupled together and requires a tool to update the data files or you have to apply JRE updates (which must be published in time). 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 :)
- rlmw 13y ago
  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.
  - apaprocki 13y ago
    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.
deleted 13y ago
[deleted]
bane 13y ago
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?
nogridbag 13y ago
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/ http://www.threeten.org/ https://github.com/ThreeTen/threetenbp https://github.com/ThreeTen/threetenbp
gldalmaso 13y ago
>> 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.
- rlmw 13y ago
  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 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 13y ago
[deleted]

84 points by javinpaul 13y ago

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.

kasey_junk 13y ago
The joda libraries are the de-facto standard. I have seen custom solutions but usually those are for lower than millisecond resolution.
- greatsuccess 13y ago
  Actually it looks like Java 8 will improve on Joda-Time, its far from perfect.
smackfu 13y 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.
bhauer 13y ago
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."
gcv 13y ago
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.
rlmw 13y ago
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.
ajanuary 13y ago
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.

moron4hire 13y ago

20 years to finally get this right. TWENTY YEARS, MAN!

melling 13y ago
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
- twic 13y ago
  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 ...".
viraptor 13y ago
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? :(
jfb 13y ago
19, you mean?
- moron4hire 13y ago
  I used Java to calculate the time difference.
  - billforsternz 13y ago
    Thank you for brightening a miserable afternoon.

bluedevil2k 13y ago

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.

yonran 13y ago
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”).
mbell 13y ago
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.

al2o3cr 13y ago

"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?

kinofcain 13y ago
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".
- nogridbag 13y ago
  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)
- rlmw 13y ago
  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 http://en.wikipedia.org/wiki/ISO_8601

fenesiistvan 13y ago

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)

brazzy 13y ago
> 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.
- fenesiistvan 13y ago
  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.
justingregoryuk 13y ago
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.
- FreezerburnV 13y ago
  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)
  - 13y ago

apaprocki 13y ago

Is there any talk in the Java world of decoupling the runtime from the tzdata distribution? AFAIK, it is still coupled together and requires a tool to update the data files or you have to apply JRE updates (which must be published in time). 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 :)

rlmw 13y ago
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.
- apaprocki 13y ago
  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.

deleted 13y ago

[deleted]

bane 13y ago

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?

nogridbag 13y ago

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/ http://www.threeten.org/ https://github.com/ThreeTen/threetenbp https://github.com/ThreeTen/threetenbp

gldalmaso 13y ago

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

rlmw 13y ago
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 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 13y ago

[deleted]