https://issues.apache.org/bugzilla/show_bug.cgi?id=56134
--- Comment #1 from A. Knauf <[email protected]> --- I did some additional digging and found out that the Java task definition instantiates a CommandlineJava object (at the very top of the class), which in its constructor determines the java executable using the following piece of code: /** * Constructor uses the VM we are running on now. */ public CommandlineJava() { setVm(JavaEnvUtils.getJreExecutable("java")); setVmversion(JavaEnvUtils.getJavaVersion()); } (CommandlineJava.java @ 225ff) The referred-to JavaEnvUtils.getJreExecutable("java") finds the first matching Java executable within a given JAVA_HOME directory. Unfortunately for Solaris, the directory structure of the JDK/JRE is like this: $JAVA_HOME/bin/ # 32bit executables: java, javac, .. $JAVA_HOME/bin/amd64/ # 64bit executables: java, javac, .. This means, regardless of environment specifications, the first matching Java executable will always be the 32bit one on this environment. In addition, the environment variable $JAVACMD which I mentioned in my initial description is only used inside the (shell, batch) wrapper scripts, so this setting will also not be honored from inside JavaEnvUtils. Does it make sense to extend the logic inside JavaEnvUtils to also take into account this variable when trying to determine which Java executable to use? Without having any further knwoledge of the code base, it seems to be as if this may be a simple extension of the getJreExecutable(..) method. However, I cannot oversee what other parts depend on it and may be affected by a change. -- You are receiving this mail because: You are the assignee for the bug.
