On some Macs that have Java 8 Update 45 (public release April 14, 2015), the Connected Backup utilities fail to run, ostensibly because of an issue with Java:
"Error: this Java instance does not support a 32-bit JVM.
Please install the desired version."
For those of you who didn't know, Connected Backup has several command line utilities:
/usr/bin/cbactivate
/usr/bin/cbbackup
/usr/bin/cbgetsettings
/usr/bin/cbretrieve
/usr/bin/cbuninstall
/usr/bin/cbupdateconfiguration
/usr/bin/cbcbupdateprofile
Most people will never use these unless for a specific purpose.
Aliases (soft links) to all the cb* utilities are placed at /usr/bin
The real utilities are found in /Library/AgentService/bin
The utility of interest here is getsettings (which is linked from /usr/bin/cbgetsettings). It produces the Java error under OS X 10.7.x, 10.8.x, and 10.9.x, but runs perfectly under 10.10.x .
In this particular environment, getsettings is being used for compliance by reporting the last backup date and status.
The following information is returned from the cbgetsettings -l -x command:
<Date>6/5/15 5:53PM</date>
<Status>Completed Successfully</Status>
This information is parsed into delicious chunks by TWO different extension attributes (one for date, one for status).
The Java error, therefore, is particularly unusual, because you would expect a higher version of the operating system to offer even less compatibility with older software.
That's when I started looking at the actual utilities, so I examined the contents of getsettings with the text editor vi:
#!/bin/sh
osversionlong=`sw_vers -productVersion`
osvers=${osversionlong:3:1}
# -d32 is not recognized by Tiger
if [ osvers -le 4 ]; then
#Tiger
javacmd='java'
else
#Leopard or Snow Leopard
javacmd='java -d32'
fi
$javacmd -Djava.library.path=/Library/ (etc...)
Here I found some version checking code that is used to run java as a 32-bit machine, or in some other way, whether it has Tiger, Leopard or Snow Leopard.
osversionlong=`sw_vers -productVersion`
osvers=${osversionlong:3:1}
Let's break down what each part does.
On any given Mac, the command "sw_vers -productVersion" would return something like this:
10.2.8
10.3.9
10.4.11
10.5.8
10.6.8
10.7.5
10.8.5
10.9.5
10.10.4
In the connected backup utilities, this value is stored in the variable osversionlong.
The next variable, osvers, (used later on in the script) is calculated by ${osversionlong:3:1} .
This means: "Take the string in the variable osversionlong, read the character in position 3, and only 1 character from that point." Since computers count from 0, we know that it's actually asking for the character in the 4th position, and ONLY that character.
So from the results above, osvers would be truncated to something like this:
10.2.8 -> 2
10.3.9 -> 3
10.4.11 -> 4
10.5.8 -> 5
10.6.8 -> 6
10.7.5 -> 7
10.8.5 -> 8
10.9.5 -> 9
10.10.3 -> 1
The next few lines are an if-then script to evaluate the version and perform an action:
if [ osvers -le 4 ]; then
#Tiger
javacmd='java'
else
#Leopard or Snow Leopard
javacmd='java -d32'
fi
"If the value of the variable osvers is less than or equal to 4, then assume this is Tiger and set the command to 'java' . Else, assume Leopard or Snow Leopard and set the command to 'java -d32' ."
Here's the thing: for quite some time now, running 'java' has defaulted to 64-bit mode. Java 8u45 must have dropped support for running 32-bit mode altogether, because computers running Java 8u40 return results without error. But these tools clearly did not take into account that a Mac could count to 10. Which explains why a Mac running Java 8u45 & Yosemite would work—the value of osvers would be "1", and 'java' , the 64-bit version, would be called—but a Mac running Mavericks & Java 8u45 would not work, because the value of osvers would be "9", and 'java -d32' would be invoked instead.
SOLUTIONS...
There are three ways to solve this:
One. Comment out or remove ALL the version checking bullcrap, change $javacmd to java, leaving only two lines behind. Make backups of your utilities, because you'll be making permanent changes that may void any service agreements with HP.
#!/bin/sh
java -Djava.library.path=/Library/ (etc...)
(note how javacmd isn't actually needed anymore).
Two. As a workaround for reporting purposes, a la an extended attribute, run the java command DIRECTLY (kudos to @makingtortillas for this suggestion):
java -Djava.library.path=/Library/AgentService/bin/ -Xmx1024m -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger -Djava.util.logging.config.file=AgentLogger.properties -cp /Library/AgentService/bin/agent.jar:/System/Library/Java com.connected.agent.cmdline.GetRegistrationInfo "$@" -l -x
Note the -l -x switches at the end: the huge java message above is just a substitute for "getsettings" , and the reason this mess is encapsulated inside a .sh script is for convenience and ease of documentation.
Three. Pester HP to fix these horribly broken utilities. (LOL)
So, just to be clear: the utility runs FINE in 64-bit mode and returns the expected results.