Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <1345921058.2051.38.camel@ubuntu>
Subject: Re: replace usage of java.util.Date in mime4j
From: Oleg Kalnichevski <olegk@apache.org>
To: mime4j-dev@james.apache.org
Date: Sat, 25 Aug 2012 20:57:38 +0200
In-Reply-To: <50390DE6.7040706@apache.org>
References: 
	<CAFvdMiBebx=dABMdRmHqNQ_ZxwyZSxJufspv+YW5mi1hYzifJQ@mail.gmail.com>
	 <5038F02C.8080805@apache.org>
	 <CAFvdMiAO49QgcPUwHj=DJYJa=d=KXgTc8kTtLQi5scvFMWpx+w@mail.gmail.com>
	 <50390DE6.7040706@apache.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0

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
> >>>
> >>>
> >>
> >
> >
> >