james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: replace usage of java.util.Date in mime4j
Date Thu, 30 Aug 2012 10:02:15 GMT
On Thu, 2012-08-30 at 11:05 +0300, Ioan Eugen Stan wrote:
> 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.
> 

Ioan, Robert, et al

Actually mime4j in its present form can be easily customized to use a
different representation / different parsing logic for jut about any
field including those containing date / time details. It basically takes
a custom of FieldParser and nothing more. The really issue is what to do
about Message interface and friends that use java.util.Date to represent
temporal attributes. It would really suck to make those interfaces
generic just to be able to a different date representation.

One possibility that I see is to create a new optional module with field
parsers based on JodaTime, but continue using java.util.Date in higher
level interfaces such as Message.

Oleg 

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



Mime
View raw message