P3 Description
Chronology is currently a class, but might be better as an interface.
While writing tests I found myself writing JapaneseChronology.from(localDate), expecting it to return a JapaneseDate. It didn't because the from method is on Chronology and intended for use in extracting the chronology from a temporal object.
The other static methods, of(String), ofLocale(Locale) and getAvailableChronologies() all suffer from the same static inheritance problem.
Using an interface fits with the package, where other Chrono classes are interfaces. It also allows the same static methods to not be inherited by subclasses, avoiding errors. Making the change would require a ChronologyImpl package scoped class to handle the current behaviour.
The right approach would be as follows:
Make Chronology into an interface
Make resolveDate abstract, and other methods on Chronology defaults
Add new public AbstractChronology class, with the resolveDate defined here
Define generics as AbstractChronology<D extends ChronoLocalDate>, which allows factory methods like date(..) to no longer need overriding in classes like MingoChronology
Define serialization as only applying to AbstractChronology
Tthe end result would be neater, with the extra abstract class simplifying external chronology implementations.
See JSR 310 issue: https://github.com/ThreeTen/threeten/issues/321
While writing tests I found myself writing JapaneseChronology.from(localDate), expecting it to return a JapaneseDate. It didn't because the from method is on Chronology and intended for use in extracting the chronology from a temporal object.
The other static methods, of(String), ofLocale(Locale) and getAvailableChronologies() all suffer from the same static inheritance problem.
Using an interface fits with the package, where other Chrono classes are interfaces. It also allows the same static methods to not be inherited by subclasses, avoiding errors. Making the change would require a ChronologyImpl package scoped class to handle the current behaviour.
The right approach would be as follows:
Make Chronology into an interface
Make resolveDate abstract, and other methods on Chronology defaults
Add new public AbstractChronology class, with the resolveDate defined here
Define generics as AbstractChronology<D extends ChronoLocalDate>, which allows factory methods like date(..) to no longer need overriding in classes like MingoChronology
Define serialization as only applying to AbstractChronology
Tthe end result would be neater, with the extra abstract class simplifying external chronology implementations.
See JSR 310 issue: https://github.com/ThreeTen/threeten/issues/321