On Sat, Aug 25, 2012 at 6:33 PM, Eric Charles <[email protected]> wrote: > Quick questions: > > - In which use case is there a thread-safety issue?
- It's used in org.apache.james.mime4j.dom.datetime.DateTime which has a getter for Date. -It's used in DateTimeField interface and Message in dom package - they leak a Date object. This means that Message's are not thread safe (another reason is that Message provides setters). > - Even if you resolve the issue related to Date, are there anything else > that would imply the system to be non thread-safe? - Message interface and implementation from dom package for starters. It should be replaced by an immutable version with a nice builder. There may e other things. > - Are there any means to measure the performance gain (a test case?)? I don't know one, besides the mini-benchmark I wrote. > 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 >> >> > -- Ioan Eugen Stan / CTO / http://axemblr.com
