I agree that adding a new dependancy is not optimal, but as a mime4j user, I love the idea of being able to use a more robust time/date library. Maybe we can have our cake and eat it too?
Would it make sense for Mime4j to abstract out the chore of constructing and storing date/time information as well as time/date formatting and parsing logic, so that users of the library can use any library of their choosing? Mime4j could default to continuing to use java.util.Date and SimpleDateFormat, but allow a caller to inject their own date/time library if desired. We'd need to define an interface that represents an "instant of time", and a default implementation that uses java.util.Date. Then we'd need to define an interface for parsing and formatting instances of time, and a default implementation of that interface that uses SimpleDateFormat et al. Finally, it would need to be made possible for a mime4j client to inject their own implementations of those interfaces prior to parsing messages. Thoughts? -Rob L -----Original Message----- From: Norman Maurer [mailto:[email protected]] Sent: Sunday, August 26, 2012 4:42 AM To: [email protected] Subject: Re: replace usage of java.util.Date in mime4j I agree with Oleg here.. I think bring in a dependency does not worth it here.. Sent from my iPhone. Excuse any typos.... Am 25.08.2012 um 20:57 schrieb Oleg Kalnichevski <[email protected]>: > On Sat, 2012-08-25 at 19:39 +0200, Eric Charles wrote: >> Thx for the info Ioan, >> >> Beside more feedback from the core developers, I would simply say >> that extra-dependency introduction is only worth if we have a obvious >> gain, so if for a very specific use case, we can make the system >> thread-safe in its globality. >> >> The best way to tackle this would be to code the use cases which >> demonstrates the thread-safety issues and also implement the benchmark. >> >> Maybe synchronization would be even or more efficient than JodaTime? >> >> Thx, Eric >> > > Ioan et al > > Presently mime4j does not have any runtime dependencies beyond > standard JRE, which is a very good thing for a low level library such as > mime4j. > Java Date and Calendar classes are generally agreed to be quite awful. > I personally fully subscribe to that opinion. At the same time I am > not sure JodaTime buys us much to outweigh the cost of having an extra > dependency. All methods in java.util.Date that can mutate its state > are deprecated. java.util.Date is not great but it is good enough. To > my knowledge date parsing / formatting is not used anywhere in the > performance critical execution paths and parsing should be done lazily > anyway. I like JodaTime a lot but am not sure it is justified in this > case. > > Oleg > > >> On 25/08/2012 18:07, Ioan Eugen Stan wrote: >>> 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/tes >>>>> t/java/org/apache/james/mime4j/util/FormatDateMiniBenchTest.java >>>>> >>>>> >>>> >>> >>> >>> > >
