james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: replace usage of java.util.Date in mime4j
Date Sun, 26 Aug 2012 09:41:46 GMT
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/test/java/org/apache/james/mime4j/util/FormatDateMiniBenchTest.java
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
> 
> 

Mime
View raw message