28609d64ef
result turn it on by default again. This change bears a little more explanation. In UnixFileSystem.java there is a cache of canonical paths and in particular one for paths inside java.home. The problem with looking up time zone data is that if another path within java.home has been looked up then the symlink for the time zone data is not resolved (since the cache assumes there are no symlinks in java.home) and we fail to be able to open the ZoneInfoMapping file. One of the other features in UnixFileSystem is that the cache is not consulted and full resolution occurs for paths containing "." or "..". I've chosen to (ab)use this to force resolution of the time zone data directory in ZoneInfoFile.java rather than doing something like IcedTea did which was to introduce a tz.properties file where they would stash the time zone info directory rather than symlinking it in. For full reference that patch is here: http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/use-system-tzdata.patch There are two main reasons I chose a bit of a hack rather than something like this. 1. I want to apply the patch to non-GPL'ed code (e.g. the jdk16 port). 2. Using updated time zone data is only an option in the port and using something like tz.properties when the option is off is clunky. Thanks to avg@ for sleuth work on finding the bug write up and the IcedTea fix. |
||
|---|---|---|
| .. | ||
| files | ||
| distinfo | ||
| Makefile | ||
| pkg-descr | ||
| pkg-message | ||