Re: Time zone data for OpenJDK 8
Hi,
On Fri, Aug 08, 2014 at 01:22:57AM +0200, Emmanuel Bourg wrote:
> Hi all,
>
> There is a pending issue with the time zone data in openjdk-8 I'd like
> to discuss.
>
> Starting with OpenJDK 8 the format of the timezone data used by the Java
> runtime is different from the previous versions. With OpenJDK 6 & 7
> there was a set of files, one per timezone, under the
> $JAVA_HOME/jre/lib/zi directory (linked from /usr/share/javazi), With
> OpenJDK 8 there is now a single tzdb.dat file in $JAVA_HOME/jre/lib.
> This means the openjdk-8 package can't use the files provided by the
> tzdata-java package.
>
> The tzdata package uses a compiler installed in
> openjdk-{6,7}-jre-headless ($JAVA_HOME/jre/lib/javazic.jar) to generate
> the javazi files. This compiler is no longer used in OpenJDK 8, a new
> one is available [1] but it isn't installed in the
> openjdk-8-jre-headless package.
>
> There are several solutions to consider:
>
> 1. Do nothing. The timezone data will be updated with the quarterly
> updates of OpenJDK.
>
> 2. Copy the sources of the compiler (13 files) into the tzdata package.
> The compiler will be built along tzdata and used to generate the
> tzdb.dat file. This is the path followed by the tzdata package in Fedora
> [2].
>
> 3. Build the compiler and install it in the openjdk-8-jre-headless
> package. This is similar to the OpenJDK 6 & 7 package. tzdata will then
> build depend on openjdk-8-jre-headless and invoke the compiler to
> generate tzdb.dat. This adds an extra jar in openjdk-8-jre-headless that
> is only useful to the tzdata package though.
>
> 4. Create a new libtzdbtools-java package containing the compiler, and
> make tzdata build depend on it. This libtzdbtools-java package could be
> generated from the openjdk-8 source package or made independent by
> extracting the tzdb compiler sources into a new package.
>
> 5. Implement a java.time.zone.ZoneRulesProvider [3] that reads the TZif2
> files installed by the tzdata package in /usr/share/zoneinfo. This would
> render the tzdata-java package obsolete in the long term. GNU ClassPath
> has a TZif2 parser [4] that could be used as a starting point.
>
> From a technical point of view my preference would be #5, #4, #3, #2 and
> #1. The option #5 avoids data duplication between the tzdata and
> tzdata-java packages, but it may take some time to get right and I doubt
> it'll be ready for Jessie. #4 means another run through the NEW queue
> which is risky if we want it in time for Jessie (but maybe we can
> convince the ftp masters to give it priority).
>
> From a practical point of view my preference would be #2, #1, #3, #4 and
> #5. #2 is easy to do right now and requires less coordination between
> tzdata and openjdk-8 (tzdata can be updated in unstable before openjdk-8
> transitions from experimental to unstable). #1 isn't that bad if the JDK
> is updated frequently. #5 could be a longer term goal for Jessie+1.
>
> What do you think? If we can settle on a solution I'll start working on
> it at the end of the month.
I am really reluctant to add yet another format of tzdata. Another
possible solution not listed above is to modify openjdk-8 to use the
same format as openjdk-8. As far as I understand, it should be about
porting the openjdk-7 code to openjdk-8.
If that is not possible, I guess we can go with #2 for jessie, and drop
that a bit before the jessie + 1 freeze so that we make sure that #5 is
implemented.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: