A DESCRIPTION OF THE PROBLEM :
https://bugs.java.com/bugdatabase/view_bug?bug_id=4391434 is the original report against Java1. This has been an issue since the year 2000. For some reason the issue was closed as "not an issue" when indeed it IS an issue. Java is supposed to be a "write once run anywhere" language and yet the manner in which the tmp directory is reported is inconsistent across platforms.
Why does this matter?
First and foremost this behavior is not documented. The API page just says it gets you the tmp directory (see https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/System.html#getProperties()). The developer has no way of knowing this is a thing unless they do what we did and waste a few hours bug hunting why the "write once run anywhere" language was having problems running the same code only on one specific OS.
Second - depending on how the developer is looking at paths this results in other unexpected behavior. One example is when a developer is splitting a path string based on what java reports as the tmp directory.
For example - this is the same tmp path being split by what java reported as the tmp directory in two different OS environments. In both cases the path was located as a subdirectory of system tmp and the developer split the path string based on the result of System.getProperty("java.io.tmpdir"):
ubuntu:
11:51:57.053 [main] DEBUG i.p.w.handlers.UploadHandler - splitFilePath is: [, ac42b50c-97a8-4cf3-903d-68a097456aab, gradle_project_sample, gradle_depgraph.txt]
macos
10:43:37.274 [main] DEBUG i.p.w.handlers.UploadHandler - splitFilePath is: [e121d5f9-d190-48e3-a1fa-46c83f3d5d7b, gradle_project_sample, gradle_depgraph.txt]
note how the ubuntu list has four elements while the macos list has only three. This is because on macos, java reports the tmp directory with a trailing '/' and on ubuntu it does not.
Whomever dismissed the initial bug report was flat wrong. The whole point of Java is to be "write once run everywhere" and stuff like this is why most people think of Java as a "write once debug everywhere" language. In order to be a "write once run everywhere" language THE BEHAVIOR OF THE LANGUAGE HAS TO BE CONSISTENT EVERYWHERE!
AT MINIMUM y'all need to document this behavior so devs know to watch out for this. HOPEFULLY y'all will take the additional step to actually standardize the behavior of how java reports the system tmp directory so this isn't an issue for anyone anymore.
FREQUENCY : always
https://bugs.java.com/bugdatabase/view_bug?bug_id=4391434 is the original report against Java1. This has been an issue since the year 2000. For some reason the issue was closed as "not an issue" when indeed it IS an issue. Java is supposed to be a "write once run anywhere" language and yet the manner in which the tmp directory is reported is inconsistent across platforms.
Why does this matter?
First and foremost this behavior is not documented. The API page just says it gets you the tmp directory (see https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/System.html#getProperties()). The developer has no way of knowing this is a thing unless they do what we did and waste a few hours bug hunting why the "write once run anywhere" language was having problems running the same code only on one specific OS.
Second - depending on how the developer is looking at paths this results in other unexpected behavior. One example is when a developer is splitting a path string based on what java reports as the tmp directory.
For example - this is the same tmp path being split by what java reported as the tmp directory in two different OS environments. In both cases the path was located as a subdirectory of system tmp and the developer split the path string based on the result of System.getProperty("java.io.tmpdir"):
ubuntu:
11:51:57.053 [main] DEBUG i.p.w.handlers.UploadHandler - splitFilePath is: [, ac42b50c-97a8-4cf3-903d-68a097456aab, gradle_project_sample, gradle_depgraph.txt]
macos
10:43:37.274 [main] DEBUG i.p.w.handlers.UploadHandler - splitFilePath is: [e121d5f9-d190-48e3-a1fa-46c83f3d5d7b, gradle_project_sample, gradle_depgraph.txt]
note how the ubuntu list has four elements while the macos list has only three. This is because on macos, java reports the tmp directory with a trailing '/' and on ubuntu it does not.
Whomever dismissed the initial bug report was flat wrong. The whole point of Java is to be "write once run everywhere" and stuff like this is why most people think of Java as a "write once debug everywhere" language. In order to be a "write once run everywhere" language THE BEHAVIOR OF THE LANGUAGE HAS TO BE CONSISTENT EVERYWHERE!
AT MINIMUM y'all need to document this behavior so devs know to watch out for this. HOPEFULLY y'all will take the additional step to actually standardize the behavior of how java reports the system tmp directory so this isn't an issue for anyone anymore.
FREQUENCY : always
- relates to
-
JDK-4391434 JCK: java.io.tmpdir system property value differs from solaris and windows value
-
- Closed
-