TimeZone cannot find time zone if called after Class.getResource(..)

[Denys Rtveliashvili]

1. Reproducible at least on Ubuntu 9.10 desktop, amd64 with the following java version:

java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)

-----------------
ia32-sun-java6-bin:
  Installed: 6.20dlj-0ubuntu1.9.10
  Candidate: 6.20dlj-0ubuntu1.9.10
  Version table:
 *** 6.20dlj-0ubuntu1.9.10 0
        500 http://gb.archive.ubuntu.com karmic-updates/multiverse Packages
        100 /var/lib/dpkg/status
     6-15-1 0
        500 http://gb.archive.ubuntu.com karmic/multiverse Packages
-----------------

Only 32bit JVM is affected (ia32-sun-java6-bin).

2. How to reproduce:

Compile and run the following Java class:

------------CUT-------------
import java.util.TimeZone;

public class Test {
 public static void main(String[] args) throws Exception {
  String.class.getResource("abc");
  TimeZone tz1 = TimeZone.getTimeZone("EST5EDT");
  System.out.println(tz1.getID());
 }
}
------------CUT-------------
You will see "GMT" in the console. It means that Java was unable to locate information on EST5EDT time zone. In fact, it does not know anything about time zones at all in this case.

However, if you move the "getResource" call one line lower so that the TimeZone is located earlier...

------------CUT-------------
import java.util.TimeZone;

public class Test {
 public static void main(String[] args) throws Exception {
  TimeZone tz1 = TimeZone.getTimeZone("EST5EDT");
  String.class.getResource("abc");
  System.out.println(tz1.getID());
 }
}
------------CUT-------------

You will see "EST5EDT" in the console, which confirms that Java was able to find the time zone information.

----
I have tried reproducing the code on 32 bit JVM of the same version downloaded from Sun. The bug does not reproduce there. This means, I believe, that the bug might be somehow related to the way the JVM is installed in Ubuntu.Java.

[Denys Rtveliashvili (rtvd)]

The same problem is in Lucid Lynx.

[Druid Squirrel (druidsquirrel)]

I've learned a little more about this. Hopefully some of this will be useful to people who want to work around the issue, or to Ubuntu package managers who have the power to fix it.

The problem is that, when multiple versions of the JVM are installed, the timezone directory (jre/lib/zi) is shared via a symlink. Presumably this was done to save disk space, but it turns out to be a bad idea. Each JVM should have its own copy of the timezone data.

So, for users, the most basic workaround is to replace the symlinked zi directory with a copy. To give a specific example: On my machine, the directory:

/usr/lib/jvm/ia32-java-6-sun-1.6.0.22/jre/lib/zi

is a symlink to

../../../java-6-sun-1.6.0.22/jre/lib/zi/

If i remove the symlink and copy the contents of the target dir to a new (real) zi directory, the problem is fixed.

There is another workaround that does not involve copying files. The downside is that you have to add a java System property to the command line whenever you run a Java program: "-Dsun.io.useCanonCaches=false" will do the trick.

The underlying problem is that Java (specifically java.io.UnixFileSystem) has a caching mechanism that gets confused by sym links that live under ${java.home}. Based on the comments in the source file, the caching mechanism assumes that there are no symlinks under ${java.home}, but that assumption is false on Ubuntu.

So, we seem to have 3 options:

1. Get the Java people to get rid of that assumption; or

2. Get Ubuntu to stop using symlinks under ${java.home}; or

3. Use the -Dsun.io.useCanonCaches=false system property to bypass the broken caching system entirely.