james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: replace usage of java.util.Date in mime4j
Date Sat, 25 Aug 2012 17:39:50 GMT
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

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/test/java/org/apache/james/mime4j/util/FormatDateMiniBenchTest.java
>>>
>>>
>>
>
>
>

Mime
View raw message