[threeten-dev] Review for #198 Chrono Initialization and Service Loader

[Xueming Shen]

It appears the spec does not specify clearly whether or not the
getAvailableChronologies() and this class support dynamically lookup,
means new chronology can be added dynamically during the lifetime
of jvm via the service loader.

Is it intended that the of(String id) to be case sensitive when
it's "id"? It may be worth specifying it explicitly, even it is
specified in LDML (I'm not sure about this)

The implementation note uses "This interface..."

-Sherman


On 01/09/2013 09:03 AM, Roger Riggs wrote:
> Please review this fix for the issue with Chronology initialization and the ServiceLoader.
>
>    http://cr.openjdk.java.net/~rriggs/webrev-serviceloader/
>
> The initialization of the lists of Chronologies is deferred until it is needed
> for the list of available Chronologies or to get a Chronology by name.
>
> The change exposed an issue with caching calendars that may be thread context
> specific which is not yet resolved. To support extended Calendars from application specific
> classloaders, caching should be limited to those in the bootclassloader.
> Additional code will be needed in the Chrono.of() and Chrono.getAvailableChronologies()
> methods to use the Thread's context and look for additional Chronologies.
> For client runtimes, this may be not necessary or useful but for server use
> the application server runtime may need to be able to support application specific
> calendar implementations.
>
> Tests for the serviceloader and extensible calendars have been added using the
> Coptic calendar as a test calendar.
>
> Opinions?
>