In Joda-time 2.0, changes were made to make the code compliant with the Java 5 memory model, but without breaking compatibility. The solution was to define several fields as volatile, because declaring them as final would break subclasses or serialization.
Making the BaseDateTime fields volatile has a measurable performance impact, nullifying (or worse) many of the performance gains Joda-time has over the JDK date classes. It's possible to make these fields final while still preserving serialization compatibility. The trick is to use special object stream features. For this to work, the field definitions need to be moved to all the subclasses, and the get/setMillis need to be abstract. The object stream stuff also needs to move to the subclasses. There's one little issue: These changes break compatibility for anyone that is extending BaseDateTime. Although this is an implementation package, and so no one _should_ be extending it, is anyone out there actually doing this? ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
