On 22 March 2012 10:05, Jörg Schaible <joerg.schai...@scalaris.com> wrote: > while I know that joda-time requires Java 5 since version 2.0, I can see > still some stuff (only from a first look), where Java 5 is not yet used in > its full breadth. While this all seems to be nit-picking, I'd actually like > to address them nevertheless especially with the perspective to get this API > into the JDK.
Joda-Time isn't going into the JDK, JSR-310 might be, but thats a different API. > 1/ copy method > > MutableDateTime, MutableInterval and MutablePeriod define a superfluous copy > method. The clone method can now return the appropriate type directly, so a > type cast is no longer necessary. True. The clone methods could be added, but i wouldn't remove the copy methods for backwards compatibilty. > 2/ Chronology.withUTC, Chronology.withZone > > According to documentation an implementation should return an instance of > the same type with different zone i.e. all implementations can return now > the appropriate type directly. True, and probably worth doing. > 3/ PeriodPrinter.printTo, DateTimePrinter.printTo > > Both interfaces define printTo methods that use a StringBuffer as argument. > It is be better to use an AbstractStringBuilder now instead. That would be backwards incompatible. Feel free to fork on GitHub and send pull requests with tests! Stephen ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
