We have spotted in legacy code, designed to work in a single thread context, something like:
DateFormatter formatter = // ... // ... Calendar cal = Calendar.getInstance(); cal.set(Calendar.YEAR, 1970); cal.set(Calendar.MONTH, Calendar.JANUARY); cal.set(Calendar.DAY_OF_MONTH, 1); String formatted = formatter.getFormat().format(cal.getTime());We know that DateFormatter, a Swing class used to format java util Date, is non thread safe. And now we plan to use this code in a multithreaded environment. We need to refactor it.
If we need to stick to the DateFormatter, here is a possible solution:
ThreadLocal<DateFormatter> formatter = // 1 ThreadLocal.withInitial( // 2 () -> new DateFormatter( // 3 new SimpleDateFormat("dd-MMM-yyyy", Locale.ENGLISH))); // 41. Wrapping an instance of it in a ThreadLocal saves our day, since each thread has its own copy of the variable.
2. Since Java 8, the withInitial() static method let us create a ThreadLocal passing a Supplier that is going to be used to initialize the object.
3. That's the Supplier. Nothing is passed in, and it returns a new DateFormatter.
4. The DateFormatter will be constructed from this SimpleDateFormat built on the fly specifying the format as a string. Notice the second parameter, I want the dates to be localized in English whichever is the default locale.
Job done. Still it would be nice to ...
Switch to java.time
The classes in java.time have been designed for working correctly in multithreading. So, getting rid of Calendar and DateFormatter for LocalDate and DateTimeFormatter, would lead to code simpler and more robust, like this:
DateTimeFormatter formatter8 = DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.ENGLISH); // ... LocalDate aDate = LocalDate.of(1970, 1, 1); String formatted = formatter8.format(aDate);I have pushed the above Java code in my GitHub repository forked from the one gently provided by the author.
Follow the links to see the Question2 solution and its test case.
No comments:
Post a Comment