JDK-8167546 : enhance os::file_name_strncmp() on Mac OSX
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2016-10-11
  • Updated: 2019-05-28
  • Resolved: 2018-10-10
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 12
12Resolved
Related Reports
Duplicate :  
JDK-8211723 - AppCDS: referring to a jar file in any way other than exactly how it was done during dumping doesn't work
Relates :  
JDK-8211723 - AppCDS: referring to a jar file in any way other than exactly how it was done during dumping doesn't work
Description
The implementation of os::file_name_strncmp() for Mac OS X in os_bsd.inline.hpp does a strcmp(). However, depending on the file system and setting on Mac OS X, it could be case-insensitive. The implementation should take that into account and call the appropriate function.

The following link has some info on the OS X file system:
http://apple.stackexchange.com/questions/8016/hfs-case-sensitive-or-case-insensitive-which-type-to-use-for-the-primary-dri
Comments
This issue will be addressed by the encompassing enhancement 8211723
10-10-2018
The latest webrev with a working solution http://cr.openjdk.java.net/~gziemski/8167546_rev5/index.html
10-10-2018
Thanks to Calvin for pointing out what I was missing: it turns out that I should have been using the "-XX:ExtraSharedClassListFile=my.list " when dumping the shared archive. I skipped that argument because the bug report showed the attached "my.list" file as size "0.0 kB", so I assumed it was empty and inconsequential - my mistake. Now, I can indeed reproduce the issue, on to the analysis...
21-09-2018
Attaching the log Calvin provided me (removed all personal info). Lines 109-115 are of particular interest: executing: '/Users/user/Downloads/temp/jdk-12/fastdebug//bin/java -cp hello1.jar -XX:+UnlockDiagnosticVMOptions -Xshare:on -XX:SharedArchiveFile=my.jsa1 Hello' Hello World OK executing: '/Users/user/Downloads/temp/jdk-12/fastdebug//bin/java -cp Hello1.jar -XX:+UnlockDiagnosticVMOptions -Xshare:on -XX:SharedArchiveFile=my.jsa1 Hello' Hello World OK The first command corresponds to the use case that was reported as working (i.e. "java -cp hello1.jar ...") , the next one (i.e. "java -cp Hello1.jar ...") failed for Calvin, but here (i.e the script) it works fine. Note: "hello1.jar" is the same as "hello.jar" attached to this issue.
20-09-2018
I have attached test.zip that contains a script of various commands that report Mac info (OS/volumes) as well as trying various java commands with various name case sensitivity to try and reproduce the issue. I can't, so far, reproduce it, and the same step in my script as the one that Calvin reported as failing for him on this issue, did not reproduce for him on his own Mac, so I am stumped. The only thing I can think of is that Calvin did something different, and until I get new steps/files to use to reproduce I am afraid that I'm out of things to try. Or I am still missing something. I tried my own script on 4 Macs that I own, all pass, can't reproduce. Tried various file systems too.
20-09-2018
Nope, even on "Journaled HFS+" (case insensitive) things work for me as expected: # cd "/Volumes/Untitled" # ./a.out Filesystem is NOT case sensitive # jdk/bin/java -jar hello.jar Hello world # jdk/bin/java -jar Hello.jar Hello world # jdk/bin/java -cp ./hello.jar -Xshare:on -XX:SharedArchiveFile=./my.jsa hello Hello world # jdk/bin/java -cp ./Hello.jar -Xshare:on -XX:SharedArchiveFile=./my.jsa hello Hello world
14-09-2018
So it looks like on older filesystems like HFS (i.e. pre APFS) things apparently work different - need to test on HFS+
14-09-2018
Works the exact same for me with just "java -jar" --------------------------------------------------------------------------------------------- #1 using /Volume/Play (case insensitive) # cd /Volume/Play # java -jar hello.jar Hello world # java -jar Hello.jar Hello world --------------------------------------------------------------------------------------------- #2 using /Volume/Work (case sensitive) # cd /Volume/Work # java -jar hello.jar Hello world # java -jar Hello.jar Error: Unable to access jarfile Hello.jar As expected.
14-09-2018
Good use cases Calvin, using your steps here is what I get with 2 file systems on my Mac: #1 /Volume/Play is NOT case sensitive #2 /Volume/Work is case sensitive --------------------------------------------------------------------------------------------- #1 using /Volume/Play # cd /Volumes/Play # ./a.out Filesystem is NOT case sensitive # ll *.jar -rw-r--r-- 1 gerard admin 799 Sep 14 10:19 hello.jar # /Volumes/Work/bugs/8204294/jdk12/build/xcode/build/jdk/bin/java -cp ./hello.jar -Xshare:on -XX:SharedArchiveFile=./my.jsa hello Hello world # /Volumes/Work/bugs/8204294/jdk12/build/xcode/build/jdk/bin/java -cp ./Hello.jar -Xshare:on -XX:SharedArchiveFile=./my.jsa hello Hello world --------------------------------------------------------------------------------------------- #2 using /Volume/Work, # cd /Volumes/Work # ./a.out Filesystem is case sensitive # ll *.jar -rw-r--r-- 1 gerard admin 799 Sep 14 10:19 hello.jar # /Volumes/Work/bugs/8204294/jdk12/build/xcode/build/jdk/bin/java -cp ./hello.jar -Xshare:on -XX:SharedArchiveFile=./my.jsa hello Hello world # /Volumes/Work/bugs/8204294/jdk12/build/xcode/build/jdk/bin/java -cp ./Hello.jar -Xshare:on -XX:SharedArchiveFile=./my.jsa hello Error: Could not find or load main class hello Caused by: java.lang.ClassNotFoundException: hello --------------------------------------------------------------------------------------------- Which works as expected: - on a file system "/Volume/Play", which IS NOT case sensitive, referring to "hello.jar" as "hello.jar" or "Hello.jar" works as expected - on a file system "/Volume/Work", which IS case sensitive, referring to "hello.jar" as "hello.jar" works, but "Hello.jar" does not, as expected Are you sure you determined whether your system is case sensitive correctly? How many devices do you have on that Mac? Did you run your "touch" test AND your java tests on the same device? Can you repeat your testing using full paths (show "pwd" command) and use my code in "main.cpp" attached to the issue (compile as "gcc main.cpp").
14-09-2018
My MacBook is running Sierra 10.12.6. Its file system is case insensitive according to "disk utility" -> info. I verified that it is the case. MacBook-Pro-2:temp cccheung$ touch xyz1 MacBook-Pro-2:temp cccheung$ touch XYZ1 MacBook-Pro-2:temp cccheung$ ls X* ls: X*: No such file or directory MacBook-Pro-2:temp cccheung$ ls x* xyz1 (Note: only one xyz1 file was created) Below is a simple AppCDS scenario when the name of a jar file should be treated as case insensitive but wasn't. Dump an archive: $MYJDK/bin/java -cp ./hello.jar -Xshare:dump -XX:ExtraSharedClassListFile=my.list -XX:SharedArchiveFile=./my.jsa Run with the archive: 1) using the original lower case for the jar file name: (no problem) $MYJDK/bin/java -cp ./hello.jar -Xshare:on -XX:SharedArchiveFile=./my.jsa Hello Hello World 2) specifying the jar as Hello.jar. For a case insensitive file system, either name (hello.jar or Hello.jar) should work. But... $MYJDK/bin/java -cp ./Hello.jar -Xshare:on -XX:SharedArchiveFile=./my.jsa -Xlog:class+path=info Hello [0.006s][info][class,path] bootstrap loader class path=/Users/cccheung/Downloads/temp/jdk-12/fastdebug/lib/modules [0.006s][info][class,path] opened: /Users/cccheung/Downloads/temp/jdk-12/fastdebug/lib/modules [0.019s][info][class,path] type=BOOT [0.019s][info][class,path] Expecting BOOT path=/Users/cccheung/Downloads/temp/jdk-12/fastdebug/lib/modules [0.019s][info][class,path] ok [0.019s][info][class,path] type=APP [0.019s][info][class,path] Expecting -Djava.class.path=./hello.jar [0.019s][info][class,path] [0.019s][info][class,path] [APP classpath mismatch, actual: -Djava.class.path=./Hello.jar An error has occurred while processing the shared archive file. shared class paths mismatch (hint: enable -Xlog:class+path=info to diagnose the failure) Error occurred during initialization of VM Unable to use shared archive.
13-09-2018
Using the same hello.jar, if I just run it using -cp, it works. MacBook-Pro-2:temp cccheung$ $MYJDK/bin/java -cp ./Hello.jar Hello Hello World MacBook-Pro-2:temp cccheung$ $MYJDK/bin/java -cp ./hello.jar Hello Hello World Probably the core-lib side is doing string compare correctly on Mac OS X. The bug in vm is in os_bsd.inline.hpp inline int os::file_name_strncmp(const char* s1, const char* s2, size_t num) { return strncmp(s1, s2, num); } The above is doing case-sensitive string comparison. For a case-insensitive file system, it should use: strnicmp() instead.
13-09-2018
The issue is about this code in os_bsd.inline.hpp: // File names are case-insensitive on windows only inline int os::file_name_strncmp(const char* s1, const char* s2, size_t num) { return strncmp(s1, s2, num); } To note, "strncmp" itself is case sensitive and furthermore "file_name_strncmp" is NOT called with CDS ON (tested with the patch that turns CDS ON by default) The only time this can come up is if #1 we programmatically generate file names #2 we hardcode same paths or #3 a user manually specifies paths, with different name cases on case sensitive file system. We would have noticed #1 or #2 by now. #3 would be considered a user error. For example: a user generates CDS archive named "Archive", and then gets sloppy and later refers to it, on case sensitive file system, as "archive" (on case insensitive file system, this would work) It should be a norm, on case sensitive file system, to expect "Archive" and "archive" to refer to different files. I don't think this is an issue, tested with CDS ON on both case sensitive and case insensitive file system.
13-09-2018
Page with some useful info: http://stackoverflow.com/questions/4706215/mac-os-x-how-to-determine-if-filesystem-is-case-sensitive
12-10-2016