[threeten-dev] Some observations of chrono ser

[Xueming Shen]

Hi,

(1) Chronology.writeReplace() is private, so the proxy Ser mechanism
is actually disabled for all Chronology subclasses. Is it intentional? Given
all JDK subclasses all have readResolve() defined (3 out of 4 to return
the singleton) I would assume the Ser delegation might not be necessary,
though it might be still desirable to "enforce" the Ser pattern here?

(2) Chronology.initCache() tries to load the Chronology implementation
from the ServiceLoader before initializing/registering the built-ins, is it
intentional? If yes, the current implementation as described in (1) may
have an un-desired impact to this design intention. For example, if a
Japanese Chronology in a VM with built-in ja chronology is transferred
to a VM that has a "customized" Japanese Chronology registered, the
current implementation may force to use the built-in (as the Ser mechanism
is off/out now), the Chronology.of(id) logic in Chronology.readExternal()
will never kick in and the "registered/customized" Japanese chronology
will not be used for the deser-ed chronology.

(3) ChronoDateImpl also declares "Serializable", given all its subclasses have
their own declaration of Serializable() and the writeReplace()/write/read
External(), this might not be necessary?

-Sherman