Reaction score: 746
If you're working in a security sensitive environment, then please read this through.
Please refrain from ever trusting a property obtained via the System#getProperty(String) subroutine! Actually, almost every property including os.arch, os.name, and os.version isn't readonly as you'd might expect — instead, they're actually quite the opposite.
First of all, any code with sufficient permission of invoking the System#setProperty(String, String) subroutine can modify the returned literal at will. However, that's not necessarily the primary issue here, as it can be resolved through the use of a so called SecurityManager, as described in greater detail over here.
The actual issue is that any user is able to edit these properties when running the JAR in question (through -Dos.name=, -Dos.arch=, etc.). A possible way to avoid tampering with the application parameters is by querying the RuntimeMXBean as shown here. The following code snippet should provide some insight into how this may be achieved.
Reaction score: 38
Reaction score: 333
Java can be made to work. I suspect the problem is the programmers of this closed source app.Yes. Java has not worked.
More likely and less obnoxious explanation: The program is actually OS dependent. For example, it might be using facilities like sysctl (on *BSD) versus the /sys file system (on Linux), or have path dependencies that can't be worked around. We have to recognize that efforts to make programs OS-independent (which includes Codasyl, POSIX, Java, ...) have reasonable well succeeded for user-level programs, but when it gets into system tasks, life is still OS dependent. So pretending that FreeBSD is Linux (with a hacked JVM or the UNAME_... environment variable override) is likely to just expose that this program won't work anyway.An OS-dependent Java app seems completely contrary to the point of Java