james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: replace usage of java.util.Date in mime4j
Date Sun, 26 Aug 2012 09:08:50 GMT
Apache Axiom uses mime4j to parse MTOM and SwA messages. We would
definitely like to avoid the additional dependency on JodaTime. Note
that Axiom doesn't need to parse any date headers. Therefore we would
still be OK with the switch to JodaTime if at runtime that dependency
is only required if there are date headers. In Axiom, we could then
simply exclude JodaTime as transitive dependency of mime4j.

Andreas

On Sat, Aug 25, 2012 at 8:57 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
> 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