You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by Ioan Eugen Stan <st...@gmail.com> on 2012/08/25 17:25:00 UTC
replace usage of java.util.Date in mime4j
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
--
Ioan Eugen Stan / CTO / http://axemblr.com
Re: replace usage of java.util.Date in mime4j
Posted by Ioan Eugen Stan <st...@gmail.com>.
I've closed the issue as I consider the review to be complete. Feel
free to re-open if you disagree.
On Thu, Aug 30, 2012 at 2:36 PM, Stefano Bagnara <ap...@bago.org> wrote:
> 2012/8/30 Oleg Kalnichevski <ol...@apache.org>:
>> [...]
>> It would really suck to make those interfaces
>> generic just to be able to a different date representation.
>
> +1
>
>> 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.
>
> +1
>
> Stefano
--
Ioan Eugen Stan / CTO / http://axemblr.com
Re: replace usage of java.util.Date in mime4j
Posted by Stefano Bagnara <ap...@bago.org>.
2012/8/30 Oleg Kalnichevski <ol...@apache.org>:
> [...]
> It would really suck to make those interfaces
> generic just to be able to a different date representation.
+1
> 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.
+1
Stefano
Re: replace usage of java.util.Date in mime4j
Posted by Oleg Kalnichevski <ol...@apache.org>.
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, <Ro...@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 <ol...@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 <er...@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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
>
>
>
Re: replace usage of java.util.Date in mime4j
Posted by Ioan Eugen Stan <st...@gmail.com>.
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, <Ro...@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 <ol...@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 <er...@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
RE: replace usage of java.util.Date in mime4j
Posted by Ro...@Dell.com.
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 <ol...@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 <er...@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
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
>
Re: replace usage of java.util.Date in mime4j
Posted by Norman Maurer <no...@googlemail.com>.
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 <ol...@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 <er...@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
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>
>
Re: replace usage of java.util.Date in mime4j
Posted by Andreas Veithen <an...@gmail.com>.
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 <ol...@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 <er...@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
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>
>
Re: replace usage of java.util.Date in mime4j
Posted by Oleg Kalnichevski <ol...@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 <er...@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
> >>>
> >>>
> >>
> >
> >
> >
Re: replace usage of java.util.Date in mime4j
Posted by Eric Charles <er...@apache.org>.
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
On 25/08/2012 18:07, Ioan Eugen Stan wrote:
> On Sat, Aug 25, 2012 at 6:33 PM, Eric Charles <er...@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
>>>
>>>
>>
>
>
>
Re: replace usage of java.util.Date in mime4j
Posted by Ioan Eugen Stan <st...@gmail.com>.
On Sat, Aug 25, 2012 at 6:33 PM, Eric Charles <er...@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
>>
>>
>
--
Ioan Eugen Stan / CTO / http://axemblr.com
Re: replace usage of java.util.Date in mime4j
Posted by Eric Charles <er...@apache.org>.
Quick questions:
- In which use case is there a thread-safety issue?
- Even if you resolve the issue related to Date, are there anything else
that would imply the system to be non thread-safe?
- Are there any means to measure the performance gain (a test case?)?
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
>
>