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

[Stephen Colebourne]

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