JDK-7050570 : (fs) FileSystemProvider fails to initializes if run with file.encoding set to Cp037
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2011-06-01
  • Updated: 2018-02-23
  • Resolved: 2013-10-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b115Fixed
Related Reports
Duplicate :  
Relates :  
Description
If JCK tests run under EBCDIC simulator ~500 test groups with ~2000 test cases fail to initialize with the following exception:

FAILED: Unexpected java.lang.ExceptionInInitializerError
    Caused by java.lang.RuntimeException: default directory must be absolute
java.lang.ExceptionInInitializerError
        at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
        at java.nio.file.Paths.get(Paths.java:84)
        at javasoft.sqe.tests.api.java.nio.file.Path.ObjectTests$2.runTest(ObjectTests.java:131)
...

All subsequent actions fail respectively with:

FAILED: Unexpected java.lang.NoClassDefFoundError: Could not initialize class java.nio.file.FileSystems$DefaultFileSystemHolder
java.lang.NoClassDefFoundError: Could not initialize class java.nio.file.FileSystems$DefaultFileSystemHolder
        at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
        at java.nio.file.Paths.get(Paths.java:84)
        at javasoft.sqe.tests.api.java.nio.file.Path.ObjectTests$3.runTest(ObjectTests.java:192)
...

Comments
SUGGESTED FIX http://rain.ireland.sun.com/~ab23780/7050570/webrev/
03-06-2011

EVALUATION We don't support setting the file.encoding property like this so this is technically an unsupported configuration. That said, the issue is the provider is using the default charset (based on file.encoding) rather than sun.jnu.encoding when encoding/decoding to/from bytes. It's too late to fix this in 7.
01-06-2011