Aside from the thread-safety issue (which in Xstream is circumvented via the use of thread-locals), SimpleDateFormat causes the JDK to initialize all possible timezones, resulting in a heap overhead of about 3.5MB (measured on x86_64).
It would be better to use DateTimeFormatter and avoiding the use of the z pattern (which also triggers the initialization of the timezones).
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("ddMMyyyy HH:mm z");
formatter.parse("01012023 00:00 CEST");
triggers the time-zone initialization, while
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("ddMMyyyy HH:mm VV");
formatter.parse("01012023 00:00 Europe/Paris");
does not.
The following table summarizes the heap impact:
| Strategy |
LocalDateTime |
LocalDate |
ZoneInfo |
ZoneOffset |
Heap |
Heap Delta (vs Baseline) |
| Baseline (no timezone calls) |
180 |
0 |
0 |
0 |
1845638 |
0 |
| Single Timezone [TimeZone.getTimeZone(id)] |
180 |
0 |
0 |
0 |
1845936 |
298 |
| All timezones with all variants [DateFormatSymbols.getZoneStrings()] |
57076 |
32212 |
602 |
1455 |
5605744 |
3760106 |
| All timezones with main variants [TimeZone.getAvailableIDs()+TimeZone.getTimeZone(id)+TimeZone.getName()] |
36678 |
21674 |
632 |
1155 |
4870584 |
3024946 |
| All timezones with no variants [TimeZone.getAvailableIDs()+TimeZone.getTimeZone(id)] |
180 |
0 |
632 |
0 |
2298216 |
452578 |
Aside from the thread-safety issue (which in Xstream is circumvented via the use of thread-locals),
SimpleDateFormatcauses the JDK to initialize all possible timezones, resulting in a heap overhead of about 3.5MB (measured on x86_64).It would be better to use
DateTimeFormatterand avoiding the use of thezpattern (which also triggers the initialization of the timezones).triggers the time-zone initialization, while
does not.
The following table summarizes the heap impact: