[threeten-dev] TzdbZoneRulesCompiler

[Xueming Shen]

With Roger's comment, I took a step back to keep the ZOT and ZOTR 
un-touched for
now. To have the sun.time.zone.Ser for SZR only, it appears we can also 
save one byte
as well:-) It should be easy to simply remove the javax.time.Ser and the 
methods in
ZOT and ZOTR, if we decide to let them go.

http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler/

-Sherman

On 12/14/12 2:56 PM, Stephen Colebourne wrote:
> On 14 December 2012 20:44, Xueming Shen <xueming.shen at oracle.com> wrote:
>> This is the first draft to pull the tzdb compiler out of the core
>> javax.time.zone
>> package. "Inevitably" it brings the ZoneRulesBulder with it and then the
>> StandardZoneRules and finally the Ser:-)
> I would expect the ZoneRulesBuilder to be separated as well, as it is
> designed in quite a TZDB way.
>
>> Now ZoneOffsetTransition and ZoneOffsetTransitionRule completely outsource
>> its serialization to the Ser. Arguably, it should be fine to just leave the
>> serialization
>> stuff of these two classes to the default implementation, or further, not
>> serializable
>> at all (any third-party ZoneRules implementation, if any, can feel free to
>> implement
>> their serialization form for these two, if they are needed in their
>> ZoneRules serialization
>> form...). The implementation will be clearer, if we give up the
>> serialization of these
>> two classes. We still keep those read/write of these two for SZR.
> There is no need for ZOT and ZOTR to be independently serializable.
> Only the rules themselves need to be serializable.
>
>> There are still 2 issues in ZoneOffsetTransition class. The big one is that
>> it appears
>> we have bunch of "transitions" that have the same before and after offset
>> from the
>> builder/compiler, I have not looked into the details of these "transitions".
> They are probably due to locations where the time-zone name changed
> without changing the offset.
>
>> The small one is that the toEpochSecond() method,
>> which is
>> "frequently" used by the builder and the SZR, is it worth make it public, or
>> I should have
>> it as the utility method somewhere in sun.time.zone.
> There is a case for ZoneRules to have a getOffset(epochSecond) method
> as well. If the method has to be public then so be it.
>
>> Opinion?  the surgery is too big?
> Taking a step back, I think that ZoneRules probably does not need to
> be an interface. There are only two sensible implementations - single
> offset and complex, as per StandardZoneRules.
>
> If we made this change, then StandardZoneRules and the rules inside
> ZoneOffset would merge inside ZoneRules. Then, all the serialization
> would stay in the core. The tool would simply create the necessary
> items to pass to the standard public factory on ZoneRules.
>
> So, what you've done makes sense given where we are, but I think there
> is a better option.
>
> Stephen