[threeten-dev] [threeten-develop] Move tzdb compiler out of j.t.z

[Xueming Shen]

Stephen,

Here is the webrev of planB, with a copycat sun.tools.tzdb.ZoneRules (need
to access to the internal state of zonerules which is not currently exposed by
public apis. may need a better alternative for the name)

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

-Sherman

On 12/27/2012 07:27 AM, Xueming Shen wrote:
> Due to the lack of access to ZoneRules' serialization form directly. The "form" is actually
> inside ZoneRules now. Outsourcing (the plan B) is an alternative. I guess the performance
> will be indeed a concern, if you actually have all the historical zone date inside one tzdb.jar.
> But I still don't understand why you want to do that:-) Given the nature of how the
> tzdb database is organized, all the historical data are all included in the latest version.
> I can guess, it may be useful, if you want to recover from an invalid zdt (created early with
> an earlier version of "latest" rules" at certain point, but do you really need such an
> "infrastructure" to support such kind of "rare" case. And given the current spec and impl
> of zdt,  most developer should be happy to be able to recover simply from the ldt and
> offset info (based on what they really mean of "zdt" in their use case).
>
> We will go with plan B.
>
> -Sherman
>
> On 12/27/2012 9:58 AM, Stephen Colebourne wrote:
>> On 23 December 2012 08:18, Xueming Shen<xueming.shen at oracle.com>  wrote:
>>> Here is the webrev for moving the tzdb compiler out of j.t.z package.
>>>
>>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/tzc/
>>>
>>> The approach here appears to cause a slower startup compared to the
>>> existing one, as it uses ObjectOutput/InputStream directly to write out and
>>> read in zrules, instead of the DateOutput/InputStream, in which the existing
>>> impl can take advantage of the direct access to Ser to write out/read in
>>> "byte[]" of the zrules, so the TzdbZoneRuleProvider can do lazy-init. The
>>> compiler can't do it now because the Ser is package private.
>> Is the slow down due to ObjectInputStream, or the lack of access to Ser?
>>
>> My preference would be to duplicate the logic from Ser into the
>> builder (or possibly move it to a sun package helper class). More like
>> plan B.
>>
>> Performance reading large tzdb files has been a problem in the past,
>> which is why the format is structured as it is, and the loader
>> carefully caches byte arrays. (Used to take over 30 seconds to start).
>>
>> It is important to test and ensure that a tzdb file with a large
>> number of versions of the database also loads quickly (I'm aware that
>> Oracle may not like this scenario, but the API supports historic
>> versions and the tool should provide a mechanism to create a file that
>> has those historic versions).
>>
>> Stephen
>>
>>
>>> The plan-B is to externalize the Ser.write/read to somewhere, so the byte[]
>>> of the zrules' serialization form can be shared by the tzdb compiler (output
>>> side) and the tzdb provider (input side). Given we are talking about 600+
>>> zone (the rules number is bigger) and a total<  40k data here, I took the
>>> simple, but slow, approach. We can revisit the start-up issue later, if it
>>> indeed
>>> is a concern. Let me know if you have concern of this approach, we can go
>>> Plan-B.
>>>
>>> I brought back the test for the ZoneRulesBuilder, as promised. But it
>>> appears
>>> there is a test failure at line#805. I have not looked into the detail yet.
>>> Just
>>> wonder if you have any idea.
>>>
>>> The changes in ZoneRulesBuilder are to workaround the
>>> beforeOffset==afterOffset issue. The old implementation creates the trans
>>> even two offsets are the same (use that package private constructor which
>>> does not do sanity check), but then throw it away. The code now does the
>>> sanity check before creating the trans.
>>>
>>> -Sherman
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. ON SALE this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122712
>> _______________________________________________
>> threeten-develop mailing list
>> threeten-develop at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/threeten-develop