[threeten-dev] TzdbZoneRulesCompiler

[Xueming Shen]

That said, outsourcing the serialization implementation of ZOT/ZOTR to
sun.time.zone, together with SZR is just to consolidate those code together,
it's perfectly fine/possible to just leave these two with their Ser in 
javax.time.zone.
There is just a little code redundancy here or there.

On 12/14/12 2:03 PM, Xueming Shen wrote:
> On 12/14/12 1:37 PM, Roger Riggs wrote:
>> Hi Sherman,
>>
>> It seems a bit broken that the serialized form is in a sun.* class;  
>> it is part of
>> the spec (even indirectly).  Is there precedent in other parts of the 
>> JDK?
>
> The Ser goes with the StandardZoneRules, so it's not an issue for SZR. 
> It's a little
> strange to have the ser delegate of ZoneOffsetTransition and 
> ZoneOffsetTransitionRule.
> One of the reasons I'm suggesting simply dropping the serialization of 
> these two.
> I don't see too much value-add to have the "independent" serialization 
> form for
> these two. While they are supposed to be "part" of the ZoneRules, but 
> it's really
> not necessary to bind their serialization forms together. 
> StandardZoneRules does
> not have the obligation to build its serialization form on top of the 
> ZOT and ZOTR.
>
> There should be no impact to the size or performance of TZDB, even we 
> give up
> these two. The binary probably will still be the same. The question is 
> do we really
> want to specify, implement and maintain the customized serialization 
> form for
> these two classes, is there any benefit/advantage of doing so, 
> compared to not
> doing so. One argument to do so probably will be "the impl is there, 
> why not just
> keep it":-)
>
> -Sherman
>
>>
>> If we give up on the serialization of those two classes how does that 
>> impact
>> the size of the TZDB?
>>
>> Roger
>>
>>
>> On 12/14/2012 3:44 PM, Xueming Shen 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:-)
>>>
>>> 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 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". This was being
>>> workaround-ed by a package private constructor in 
>>> ZoneOffsetTransition, need to figure
>>> out the best solution. 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.
>>>
>>> The package name of sun.time.zone is picked, just because I don't 
>>> have a better one
>>> for now.  The "compiler" itself actually can be anywhere later, 
>>> probably will be in a
>>> "tool" area of jdk, if we indeed decide to make it public.
>>>
>>> Opinion?  the surgery is too big?
>>>
>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzcompiler
>>>
>>>
>>
>> -- 
>> Thanks, Roger
>>
>> Oracle Java Platform Group
>>
>> Green Oracle <http://www.oracle.com/commitment> Oracle is committed 
>> to developing practices and products that help protect the environment
>>
>