[threeten-dev] TzdbZoneRulesCompiler

[Xueming Shen]

If StandardZoneRules is the only class needed to be serializable in zone 
package,
Isn't Ser delegation no longer necessary? it has a short name for sure.

-Sherman

On 12/14/12 3:12 PM, Xueming Shen wrote:
> 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
>