james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Robert_E_...@Dell.com>
Subject RE: replace usage of java.util.Date in mime4j
Date Wed, 29 Aug 2012 21:14:17 GMT
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

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.


-Rob L

-----Original Message-----
From: Norman Maurer [mailto:norman.maurer@googlemail.com] 
Sent: Sunday, August 26, 2012 4:42 AM
To: mime4j-dev@james.apache.org
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 <olegk@apache.org>:

> 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 <eric@apache.org> 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

View raw message