armhf is not correctly detected on openjdk8, raspbian jessie

[blucoat]

The Loader class currently tells the difference between arm and armhf using the sun.arch.abi system property. On the latest openjdk 8 on Raspbian Jessie, this property is not set by default, which will cause libraries to fail to load.

A simple workaround is to pass this variable manually at runtime with -Dsun.arch.abi=gnueabihf.

I don't know of another way to detect the abi, but if this can't be fixed it should at least be clearly documented.

[saudet]

@vb216 What do you think we should do?

[vb216]

I wondered if this might crop up, as I picked a value based on using oracle jdk, and didn't have openjdk installed to see what info it gives

@blucoat - are you able to do a print of the system properties picked up by openjdk and post them over? There might be some equivalent that would be easy enough to add into the build. If not, I can install openjdk and take a look, will just take a little while.

[blucoat]

This is the output of System.getProperties():

{
  java.runtime.name=OpenJDK Runtime Environment,
  sun.boot.library.path=/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm,
  java.vm.version=25.40-b08,
  java.vm.vendor=Oracle Corporation,
  java.vendor.url=http://java.oracle.com/,
  path.separator=:,
  java.vm.name=OpenJDK Zero VM,
  file.encoding.pkg=sun.io,
  user.country=GB,
  sun.java.launcher=SUN_STANDARD,
  sun.os.patch.level=unknown,
  java.vm.specification.name=Java Virtual Machine Specification,
  user.dir=/home/pi/javatest,
  java.runtime.version=1.8.0_40-internal-b04,
  java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment,
  java.endorsed.dirs=/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/endorsed,
  os.arch=arm,
  java.io.tmpdir=/tmp,
  line.separator=
,
  java.vm.specification.vendor=Oracle Corporation,
  os.name=Linux,
  sun.jnu.encoding=UTF-8,
  java.library.path=/usr/java/packages/lib/arm:/usr/lib/arm-linux-gnueabihf/jni:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib,
  java.specification.name=Java Platform API Specification,
  java.class.version=52.0,
  os.version=4.4.11-v7+,
  user.home=/home/pi,
  user.timezone=America/New_York,
  java.awt.printerjob=sun.print.PSPrinterJob,
  file.encoding=UTF-8,
  java.specification.version=1.8,
  java.class.path=.,
  user.name=pi,
  java.vm.specification.version=1.8,
  sun.java.command=Test,
  java.home=/usr/lib/jvm/java-8-openjdk-armhf/jre,
  sun.arch.data.model=32,
  user.language=en,
  java.specification.vendor=Oracle Corporation,
  awt.toolkit=sun.awt.X11.XToolkit,
  java.vm.info=interpreted mode,
  java.version=1.8.0_40-internal,
  java.ext.dirs=/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/ext:/usr/java/packages/lib/ext,
  sun.boot.class.path=/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/resources.jar:/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/rt.jar:/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/jsse.jar:/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/jce.jar:/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/charsets.jar:/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/jfr.jar:/usr/lib/jvm/java-8-openjdk-armhf/jre/classes,
  java.vendor=Oracle Corporation,
  file.separator=/,
  java.vendor.url.bug=http://bugreport.sun.com/bugreport/,
  sun.io.unicode.encoding=UnicodeLittle,
  sun.cpu.endian=little,
  sun.cpu.isalist=
}

I don't see anything here that indicates hard floating point, except for directory names, which seem very system-dependant.

It looks like the sun.arch.abi property can be set when OpenJDK is compiled: https://bugs.openjdk.java.net/browse/JDK-8009195

[vb216]

Hm yes, nothing definitive, but I wonder if some logic like if the runtime name has OpenJDK in it, and maybe then if java.library.path contains arm-linux, then assume linux-armhf? It's not bullet proof, but if thats the default dir for openjdk in raspbian, it would probably cater for a high percentage of users?

[blucoat]

What about checking in platform-specific ways, like checking /proc/cpuinfo in Linux, and similar ways on other systems?

[vb216]

I'd need to have another deeper look, I think I went for Java based approach as its easy to just see the system properties. More than that and you've got to worry about platform specific filesystem access. But, I guess from the java props you would know if its Linux, you could see if /proc/cpuinfo exists and accessible, and try and handle it.

@saudet any preference?

[blucoat]

This thread mentions some possible ways other projects do it. Using readelf -A "$JAVA_HOME/java" solves the problem more directly that /proc/cpuinfo, since in theory one could run a soft floating-point distro on hard floating-point hardware.

[saudet]

I don't have any preferences with how to go about it, as long as we don't start poking in /proc/cpuinfo or trying to execute readelf on anything else than Linux and ARM :)

[vb216]

I read the thread blucoat pointed to, I remember actually reading it the
first time round I was trying to add in arm-hf. The code they developed is
probably the neat way of doing it, but it just felt like an awful lot of
lines of code to add for a seemingly small task. The slight reservation I
have about running system commands to determine things, is you never really
know what permissions you might have, both to execute and for filesystem
access. We could maybe assume that Pi's wouldnt have anything too locked
down.. but, if we're into assumptions, its also easy to search a few of the
system params for armhf and use that as the basis.

@blucoat, I wondered about soft floating on hard float too.. but I think
raspbian/pi stopped that distro a while ago.

My gut feel, is to put in the path approach, as its quick (meaning I'd have
the time to put it in soon), and might deal with most peoples use cases..?
@blucoat - happy to help if you want to work on a more advanced solution,
but I'll struggle for time to do it myself

[saudet]

@blucoat FYI, @vb216 has provided a fix in this commit: 70a3136

[saudet]

Fix is included in version 1.3, enjoy! Please let me know if you still have problems with this though.

Thanks for reporting!