[threeten-dev] TzdbZoneRulesCompiler

[Xueming Shen]

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
>