Created files have a filename of only the first requested character

[ben-walsh]

When a file is created, it has a filename which is only the first character of the string specified. This simple test shows the problem ...

import java.io.*;

public class WriteFile {

    public static void main(String[] args) {

        try {

            File out = new File("ABC.txt");

            out.createNewFile();

            System.out.println("absolutePath() : " + out.getAbsolutePath());

        } catch (Exception e) {

            System.out.println(e);

        }

   }

}

... when it is compiled and run, the file that is created has a filename of "A" rather than the expected "ABC.txt" ...

walshbp@bendev:~$ ls -ltr | tail
-rw-rw-r--  1 walshbp walshbp 199595468 Mar 22 13:01 OpenJDK9-OPENJ9_x64_Win_20182203.zip
-rwxrwxrwx  1 walshbp walshbp      5021 Mar 22 14:04 openjdk_notes.txt
-rw-rw-r--  1 walshbp walshbp 200989495 Mar 28 10:37 brokenFileWrite.jdk.tar.gz
drwxrwxr-x 15 walshbp walshbp      4096 Mar 28 10:37 openjdk-openj9-internal-work
drwxrwxr-x 13 walshbp walshbp      4096 Mar 28 11:11 openjdk-openj9-jdk10-work
drwxrwxr-x  3 walshbp walshbp      4096 Mar 28 11:31 testOpenJDK9OpenJ9
drwxrwxr-x  3 walshbp walshbp      4096 Mar 28 11:45 testOpenJDK10OpenJ9
drwxrwxr-x  3 walshbp walshbp      4096 Mar 28 11:58 testOpenJDK10Hotspot
-rw-rw-r--  1 walshbp walshbp       351 Mar 28 12:24 WriteFile.java
-rw-rw-r--  1 walshbp walshbp      1143 Mar 28 12:24 WriteFile.class
walshbp@bendev:~$ ./testOpenJDK10OpenJ9/jdk-10+46/bin/java WriteFile
absolutePath() : /home/walshbp/ABC.txt
walshbp@bendev:~$ ls -ltr | tail
-rwxrwxrwx  1 walshbp walshbp      5021 Mar 22 14:04 openjdk_notes.txt
-rw-rw-r--  1 walshbp walshbp 200989495 Mar 28 10:37 brokenFileWrite.jdk.tar.gz
drwxrwxr-x 15 walshbp walshbp      4096 Mar 28 10:37 openjdk-openj9-internal-work
drwxrwxr-x 13 walshbp walshbp      4096 Mar 28 11:11 openjdk-openj9-jdk10-work
drwxrwxr-x  3 walshbp walshbp      4096 Mar 28 11:31 testOpenJDK9OpenJ9
drwxrwxr-x  3 walshbp walshbp      4096 Mar 28 11:45 testOpenJDK10OpenJ9
drwxrwxr-x  3 walshbp walshbp      4096 Mar 28 11:58 testOpenJDK10Hotspot
-rw-rw-r--  1 walshbp walshbp       351 Mar 28 12:24 WriteFile.java
-rw-rw-r--  1 walshbp walshbp      1143 Mar 28 12:24 WriteFile.class
-rw-rw-r--  1 walshbp walshbp         0 Mar 28 12:58 A
walshbp@bendev:~$ ./testOpenJDK10OpenJ9/jdk-10+46/bin/java -version
openjdk version "10-adoptopenjdk" 2018-03-20
OpenJDK Runtime Environment (build 10-adoptopenjdk+0-adhoc.jenkins.openjdk)
Eclipse OpenJ9 VM (build master-9adecd31, JRE 10 Linux amd64-64 Compressed References 20180327_9 (JIT enabled, AOT enabled)
OpenJ9   - 9adecd31
OMR      - a05605ea
JCL      - f5e3d23b0f based on )

Internally, at the Java layer, the filename seems to be as requested.

Tried a range of builds ... latest adoptopenjdk openjdk9 + openj9 build = filename as expected latest adoptopenjdk openjdk10 + openj9 build = filename truncated to first character latest external local openjdk10 + openj9 build = filename truncated to first character adoptopenjdk openjdk10 + hotspot = filename as expected

[pdbain-ibm]

Per discussion with @pshipton , I will investigate.

[pshipton]

Initial investigation indicates the problem is related to compact strings. Using -XX:+CompactStrings makes the test case work, although this option isn't fully supported by OpenJ9 yet.

[DanHeidinga]

FYI @fjeremic

[fjeremic]

Initial investigation indicates the problem is related to compact strings. Using -XX:+CompactStrings makes the test case work, although this option isn't fully supported by OpenJ9 yet.

Wow this is the first time this has happened. It is usually the other way around. Given this is JDK10 though there must have been more compression changes elsewhere in the JCL. I know we had the one change in String from https://github.com/eclipse/openj9/pull/1466. Other culprits could include the coder changes guarded by the JAVA10 ifdef.

[pdbain-ibm]

Same problem with -Xint.

[pdbain-ibm]

Used reflection to get String.coder: it is 0 (Latin1).

[pdbain-ibm]

By default, jvminit.c processCompressionOptions() sets vm->strCompEnabled=false. Making it default to true makes the test case pass. It looks like the VM and String aren't on the same page.

[fjeremic]

Making it default to true makes the test case pass.

This is the same as specifying -XX:+CompactStrings, so not surprising.

VM and String aren't on the same page

The VM wouldn't even start up if this was the case. The bug is more subtle.

[pdbain-ibm]

The problem seems to be with constant strings. String objects created at runtime work fine, e.g.

            File out = new File("ABC.txt");
            out.createNewFile();
            File f2 = new File("foo."+args[0]);
            f2.createNewFile();

$ java  WriteFile bar
$ ls
A  foo.bar  

[pdbain-ibm]

Constant strings have their "coder" field set to 0, while runtime strings are set to 1. The coder field is set by the constructors.

[fjeremic]

Constant strings have their "coder" field set to 0, while runtime strings are set to 1. The coder field is set by the constructors.

Ah! Right. I have a patch for you to fix this. Digging it up now...

[fjeremic]

@pdbain-ibm could you try adding in the gc_base/StringTable.cpp changes from the following commit?

https://github.com/fjeremic/openj9/commit/fbcec6ce88ef0626eb1fc03c9eb18b71f32e4b39

Only the ones relevant to the coder field. This will fix the constant string issues almost certainly as I had the same problem working on a kind-of-sort-of related change.

i.e. see all the new code with J2SE_VERSION(vm) >= J2SE_19 checks. Please let me know if these actually fix the problem. I'll rip that commit out of my set of changes and open up a PR against this issue.

[pdbain-ibm]

Tested and working (with changes to fix compilation errors). Over to you @fjeremic. StringTable .cpp.txt

[sxa]

For reference, 3rd April and later builds at https://adoptopenjdk.net/nightly.html?variant=openjdk10-openj9 include the fix