A bug in filesystem bootstrap (unix/ linux) prevents (original) (raw)

Dawid Weiss dawid.weiss at gmail.com
Thu Jul 5 06:00:00 UTC 2012


Well, what's the "right" way to enforce an initial encoding for charset-less string-to-byte conversions and legacy streams? I still think that snippet of code is buggy, no matter if file.encoding is or isn't a supported settable property.

Besides, from what I see in JDK code base everything seems to be code in a way to allow external definition of file.encoding (comments inside System.c for example). Where is it stated that file.encoding is read-only?

Dawid

On Thu, Jul 5, 2012 at 3:09 AM, Xueming Shen <xueming.shen at oracle.com> wrote:

-Dfile.encoding=xyz is NOT a supported configuration. file.encoding is supposed to be a read-only informative system property.

-Sherman

On 7/4/2012 1:21 PM, Dawid Weiss wrote:

There is a similar bug: Bug 6795536 - No system start for file.encoding=x-SJIS0213 Yeah... I looked at the sources in that package and there is at least one more place which converts a String to bytes using getBytes(). This seems to be a trivial fix in UnixFileSystem though. Anyway, bug ID for this is: http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7181721 Dawid In this case on Windows. -Ulf

Am 04.07.2012 14:43, schrieb Dawid Weiss: Hi folks. Run the following with -Dfile.encoding=UTF-16: public class TestBlah { public static void main(String []) throws Exception { TimeZone.getDefault(); } } This on linux (and any unixish system I think) will result in: java.lang.ExceptionInInitializerError at java.nio.file.FileSystems.getDefault(FileSystems.java:176) at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:482) at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:477) ... There is an encoding-sensitive part calling getBytes on the initial path (and this screws it up): // package-private UnixFileSystem(UnixFileSystemProvider provider, String dir) { this.provider = provider; this.defaultDirectory = UnixPath.normalizeAndCheck(dir).getBytes(); if (this.defaultDirectory[0] != '/') { throw new RuntimeException("default directory must be absolute"); } Filed a bug for this but don't have the ID yet. Dawid



More information about the core-libs-dev mailing list