-2

In previous date time API thread are not safe.... I want to know how they achieved in new date time API in java 8?? (earlear they also can safe the thread by using synchronizing and making seprate instance for each thread ) In java 8 what they add new give some examples also... Thank you.

hc_dev
  • 8,389
  • 1
  • 26
  • 38
Abbas Pathan
  • 9
  • 1
  • 1
  • What exactly do you mean with __thread-safety__ in Java-8 _DateTime_-API ? Can you please [edit] and post some example or use-case where mentioned thread-safety would be of interest. – hc_dev Mar 19 '19 at 19:40
  • 2
    Immutable data objects, mostly. With immutable objects, you don't have to worry about thread safety at all. – Louis Wasserman Mar 19 '19 at 21:37
  • Stack Overflow is not a discussion site. For discussion, visit a site such as http://www.JavaRanch.com/. Tip: See the Wikipedia page for [*immutable object*](https://en.wikipedia.org/wiki/Immutable_object) providing [thread-safety](https://en.wikipedia.org/wiki/Immutable_object#Thread_safety). – Basil Bourque Mar 19 '19 at 22:55

2 Answers2

1

The SimpleDateFormat that's existed since the early days of Java used inner fields to hold temporary state but didn't do anything to prevent two thread concurrently updating these. This lead to the wrong date being returned if two threads happened to call the format or parse methods on the same SimpleDateFormat instance at the same time, since they'd modify the internal state of the SimpleDateFormat object whilst the other was still using that state.

Java 8 hasn't done anything to change SimpleDateFormat, instead it's introduced a whole new LocalDate API that uses internal synchronization to protect fields being accessed concurrently (and possibly uses local variables to reduce locking overhead, but I've not checked this), as well as removing the complexity of Timezones and pre-1990 dates that were also a headache for users of the old Date APIs.

mc1arke
  • 1,030
  • 10
  • 22
  • 2
    First of all, classes like `LocalDate`, `LocalDateTime`, `Instant`, etc are *immutable*, which eliminates the need for any synchronizations, as without mutation, there can’t be any inconsistencies. For the formatters, they are immutable too and hold their temporary state in local variables and locally constructed objects. The “complexity of Timezones” is still supported for those who need it, see [`ZonedDateTime`](https://docs.oracle.com/javase/8/docs/api/?java/time/ZonedDateTime.html) and it’s the first time I see someone claiming that “pre-1990 dates” were not supported. – Holger Mar 20 '19 at 09:13
  • It wasn't that pre-1990 dates weren't supported, it was the fact that 2 digit dates were post 1990 based, months were 0 based but days were 1 based, so a new user of the API had to go and read the Javadoc to have any chance of getting date handling right. – mc1arke Mar 20 '19 at 09:46
  • If you are talking about [`java.util.Date`](https://docs.oracle.com/javase/8/docs/api/?java/util/Date.html), it uses “year minus 1900”, no reference to 1990 and the inconsistencies of the representations of days and months are not mentioned in your answer. In case of `SimpleDateFormat`, the base for two-digit years [can be set](https://docs.oracle.com/javase/8/docs/api/java/text/SimpleDateFormat.html#set2DigitYearStart-java.util.Date-). So in general, it’s true that the old API was a mess, but what you’ve written in the answer is not addressing the actual issues. – Holger Mar 20 '19 at 09:54
0

The thread safety in java.time (the modern Java date and time API introduced from Java 8) is obtained through immutable classes. An immutable object is always thread-safe (see the modification of the last statement near the bottom of the first link). As Holger notes in a comment,

without mutation, there can’t be any inconsistencies.

Links:

Ole V.V.
  • 81,772
  • 15
  • 137
  • 161