Hello Robert, I also thought about externalizing the parsing part and to me this approach makes sense. It should work but I don't know exactly what it involves. I'll look into it when I get some free time. Patches/ contributions are welcomed in the mean time so if it itches you, juts scratch it.
Cheers, On Thu, Aug 30, 2012 at 12:14 AM, <[email protected]> wrote: > 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >> >> -- Ioan Eugen Stan / CTO / http://axemblr.com
