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 <[email protected]>: > 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 <[email protected]> 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 >>>>> >>>>> >>>> >>> >>> >>> > >
