james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioan Eugen Stan <stan.ieu...@gmail.com>
Subject Re: replace usage of java.util.Date in mime4j
Date Thu, 30 Aug 2012 08:05:38 GMT
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,  <Robert_E_Lee@dell.com> 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: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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>



-- 
Ioan Eugen Stan / CTO / http://axemblr.com

Mime
View raw message