[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Time zone data for OpenJDK 8

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

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.

Emmanuel Bourg


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: