Quick questions:
- In which use case is there a thread-safety issue?
- Even if you resolve the issue related to Date, are there anything else
that would imply the system to be non thread-safe?
- Are there any means to measure the performance gain (a test case?)?
Thx, Eric
On 25/08/2012 17:25, Ioan Eugen Stan wrote:
> Hello,
>
> I just took ownership of MIME4J-98 and I did a bit of research.
>
> The issue takes into account two problems:
>
> 1. parsing/formatting speed of Date (SImpleDateFormat is not thread
> safe and is slow)
> 2. java.util.Date is not suited for protocol use (does not take
> TimeZone, Locale into account, is mutable == not thread safe, etc.)
>
> Possible solutions:
>
> 1. Formatting/Parsing
>
> JodaTime and FastDateFormat from Apache Commons Lang are good
> candidates for formatting.
>
> I wrote a mini-benchmark [1] in class FormatMiniBencTest. Both are
> much faster than the original version (almost 10 times), especially
> when running in a multi-threaded environment. JodaTime seems slightly
> faster than FastDateFormat.
>
> 2. Replacement for Date
>
> FastDateFormat only does formatting. JodaTime provides a better
> alternative to java.util.Date and Calendar. JodaTime's Instant
> represents an immutable instant in time and I believe is the best
> solution to use because it takes into acount TimeZone and Chronology.
> Another option is DateTime which needs a TimeZone to represent
> absolute time.
>
> Using JodaTime will mean adding a dependency to mime4j. JodaTime is
> ASFv2 licensed and it's API is very stable (also compatible with 1.6).
>
> My recommendation is we switch to JodaTime for time management for
> performance reasons, thread safety and better date time handling.
>
> What do you think?
>
> [1] http://joda-time.sourceforge.net/
> [2] https://github.com/ieugen/james-mime4j/tree/MIME4J-98
> [3] http://commons.apache.org/lang/api-3.1/index.html
> [4] https://github.com/ieugen/james-mime4j/blob/MIME4J-98/core/src/test/java/org/apache/james/mime4j/util/FormatDateMiniBenchTest.java
>
>