[threeten-dev] TzdbZoneRulesCompiler

Roger Riggs Roger.Riggs at oracle.com
Fri Dec 14 13:37:40 PST 2012


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?

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



More information about the threeten-dev mailing list