Arduino 1:1.8.9-3(compiled with jdk9?) ByteBuffer breaks libraries

[DWShuo]

Using RF24 library for nRF24L01 upgraded arduino (1:1.8.9-1 -> 1:1.8.9-3) OS: arch linux

Following error is thrown after upgrade Exception in thread "EventThread /dev/ttyUSB1" java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer; at processing.app.Serial.serialEvent(Serial.java:185) at jssc.SerialPort$LinuxEventThread.run(SerialPort.java:1299)

Relevant github issue? https://github.com/apache/felix/pull/114

[DWShuo]

Just rolled back to package version 1:1.8.9-1, and everything works fine. Seems like 1:1.8.9-3 is indeed the issue

[facchinm]

@NicoHood maybe you lost this :wink:

[harkor]

Same issue here.

Rolling back to 1:1.8.9-1 working :)

[NicoHood]

What should I do to fix this??

[facchinm]

I think compiling with java8 should fix it

[NicoHood]

But shouldn't Arduino support java 8 and all higher versions?

[facchinm]

I think you need to compile the jars with java 8 exactly, so the dependency here should be java-runtime=8 (I think)

[DWShuo]

Ok figure it out, for some reason arch defaults to jdk8, you have to manually set java to a higher version. Do this to check which versions of java you have installed archlinux-java status if java-8-openjdk/jre is your only option then run this pacman -Syu jdk-openjdk run archlinux-java status again should have java11 now as an option switch to java11 sudo archlinux-java set java-11-openjdk

[NicoHood]

I am not very familiar with java programming. Code compiled with java will only run with java8 interpreter? Or will it run with 8 and every version above? Is the problem that I've compiled the code with java 11, but with an old java8 interpreter it crashes? Changing the OS java version does not sound like a solution, more a workaround. Can somebody please explain me better how this works?

[PaulStoffregen]

Kind of a moot point, since the Arduino IDE bundles the correct Java JRE which precisely matches the version of the Java SDK they used to build the code.

[winksaville]

@NicoHood as @PaulStoffregen says, the Java SDK should probably be used. The reason is not all Java 8's are the same.

On my arch linux system, just updated:

$ uname -a
Linux wink-desktop 5.1.9-arch1-1-ARCH #1 SMP PREEMPT Tue Jun 11 16:18:09 UTC 2019 x86_64 GNU/Linux

I have java 8 installed as my default:

$ archlinux-java status
Available Java environments:
  java-10-openjdk
  java-11-openjdk
  java-8-openjdk (default)

And the version reported by java is 1.8.0_212:

$ /usr/bin/java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b01)
OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode)

Which is slightly different from the version provided by arduino-1.8.9, 1.8.0_191:

$ ./bin/arduino-1.8.9/java/bin/java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

And I don't get the "NoSuchMethodError" when I'm using arduino-1.8.9 directly but I do get this error when I install the Arch Linux arduino package. A workaround that is suggested in the Arch Linux bug report 62704 of changing to java 10 or 11 does resolve this bug but then I get some warnings:

$ /usr/share/arduino/arduino
Picked up JAVA_TOOL_OPTIONS: 
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by processing.app.linux.GTKLookAndFeelFixer (file:/usr/share/arduino/lib/arduino-core.jar) to field com.sun.java.swing.plaf.gtk.GTKLookAndFeel.styleFactory
WARNING: Please consider reporting this to the maintainers of processing.app.linux.GTKLookAndFeelFixer
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

So it seems it would be best to change Arch Linux arduino PKGBUILD to use the java provided by arduino and not the system installed version.

[PaulStoffregen]

Seems to me this is a problem with Arch Linux. The software Arduino.cc distributes always has the correct JRE bundled, so I do not believe reporting the problem here is correct.

[toketin]

Hi, i confirm with Java 12 i had issue with the menu theme of Arduino Ide. Reinstalling Java 8 and setting: archlinux-java set java-8-openjdk/jre i can get the correct theme again.

This was the output running arduino ide with Java 12 as default:

$ arduino                   
Picked up JAVA_TOOL_OPTIONS: 
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by processing.app.linux.GTKLookAndFeelFixer (file:/usr/share/arduino/lib/arduino-core.jar) to field com.sun.java.swing.plaf.gtk.GTKLookAndFeel.styleFactory
WARNING: Please consider reporting this to the maintainers of processing.app.linux.GTKLookAndFeelFixer
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

[fam4r]

I can not access Serial using Java 8 and Arduino 1.8.9-3, but it works with Arduino 1.8.9-1.

Java 12 is not affected by that problem, but shows warnings as reported from some of you.

[serra-pablo]

I had this same issue on Arch Linux. Using java-8-jdk, the error didn't come up again (and the monitor functioned properly) after switching to java-10-openjdk. This was done by issueing the command:

archlinux-java set java-10-openjdk

[NicoHood]

Is there a way to fix java compatibility in the arduino IDE, so users do not need to switch their java version?

And another question for packaging arduino: Is the compiling java version a problem, or the running java version? From the comments I understood that only the java runtime version is important. I could add a simple wrapper around the arduino executable that forces to start with java8 (unless the bugs are fixed with newer java versions).

[molecular]

on arch, same problem, fixed by sudo archlinux-java set java-11-openjdk. Thanks @DWShuo

@PaulStoffregen, you say

Kind of a moot point, since the Arduino IDE bundles the correct Java JRE which precisely matches the version of the Java SDK they used to build the code.

Then why it isn't used when people start on arch using "#> arduino"?

[NicoHood]

@molecular A new arduino version was released on arch. Could you please try if it work with java 11 and 14 on your system?

sudo archlinux-java set java-14-openjdk

It should work with both, but please try it out.

[gkatev]

On my system with Arduino 1.8.13 from the Arch repository, the Serial monitor works with both java 11 and 14 (though it has been a little circumstantial in the past).

I don't know if java 8 is still relevant, but with java-8-openjdk, I still get an error:

Exception in thread "EventThread /dev/ttyACM0" java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
    at processing.app.Serial.processSerialEvent(Serial.java:210)
    at processing.app.Serial.serialEvent(Serial.java:183)
    at jssc.SerialPort$LinuxEventThread.run(SerialPort.java:1299)

[NicoHood]

@facchinm Is this something the arduino team is able to fix, or should I bump the minimum required java version to 11 for the arch package?

[facchinm]

@NicoHood There's a branch https://github.com/cmaglie/Arduino/tree/java-11 for java11 full compatibility but it still needs some testing. I think that forcing java-8-openjdk in AUR could be the best idea (so replacing the >=8 with ==8)

[gkatev]

@facchinm My experience is that the Serial monitor does not work with java-8-openjdk, so I don't see why this version should be forced..

On another note, what is the root cause of this bug? A method that is available in the "bundled JRE" but not in the openjdk? If it's just one misbehaving method, could we replace it with something else that works across the board?

[facchinm]

@gkatev it doesn't work because the package gets compiled using java11 if it's already installed. If you force the PKGBUILD to use jdk8 the package will run seamlessly (I'm on Arch BTW :wink: )

[NicoHood]

@facchinm thanks for this note, I will update the package! However I was unable to reproduce the bug @gkatev reported with java8. On my system the serial monitor seems to work. And I made sure, that archlinux-java was set to 8 of course.

@gkatev once the new arduino version is in the arch packages, please let me know if that works for you now on all java versions. Thanks for the feedback!

[gkatev]

@NicoHood I too have had some hit and miss results in the past. As far as I can tell from recent testing, the bug appears as soon as the device sends data on the Serial port, and not before.

I upgraded arduino to 1.8.13-2 and was still able to consistently reproduce the bug, with java-8-openjdk.

$ realpath $(which java)
/usr/lib/jvm/java-8-openjdk/jre/bin/java

I also checked some random .class file from the jars (/usr/share/arduino/lib/arduino-core.jar/processing/app/Platform.class) with a hex editor, and saw that the bytes at offset 6 & 7 are 0x0034 (=Java SE 8, according to wikipedia), confirming that they have been compiled with Java 8?

If you cannot seem to reproduce the bug yourself, I can look around and try to see what's going. Any pointers welcome!

[NicoHood]

Well then I have to ask @facchinm again :-D

[kolewu]

Problem with arch (besides the possible problems on java>8) is based on the shell runner /usr/bin/arduino:

#!/bin/sh
export PATH=/usr/lib/jvm/default-runtime/bin/:"$PATH"
exec /usr/share/arduino/arduino "$@"

PATH is wrong from different viewpoints:

• if no default runtime is defined
• if a default runtime is defined that is incompatible with arduino code (see above)
• if the default runtime is java-8-openjdk because of the error that started this thread

If I understood Nico correctly, arduino is built for Arch. So I would make the java that is used for building a hard requirement and explicitly use it here for the PATH.

I think it only runs with jdk8 if it is build with jdk8, because of an incompatible change for ByteBuffer.flip() (from hazelcast#14214):

JDK9 breaks compatibility with older versions for ByteBuffer.flip() by returning ByteBuffer instead of Buffer

[StarsoftAnalysis]

This worked for me on Arch Linux: sudo archlinux-java set java-14-openjdk but only after I then reinstalled the arduino package.

[Haradai]

This worked for me on Arch Linux: sudo archlinux-java set java-14-openjdk but only after I then reinstalled the arduino package.

I instead used java-11-openjdk and it worked too

[berkersal]

Problem with arch (besides the possible problems on java>8) is based on the shell runner /usr/bin/arduino:

#!/bin/sh
export PATH=/usr/lib/jvm/default-runtime/bin/:"$PATH"
exec /usr/share/arduino/arduino "$@"

PATH is wrong from different viewpoints:

• if no default runtime is defined
• if a default runtime is defined that is incompatible with arduino code (see above)
• if the default runtime is java-8-openjdk because of the error that started this thread

If I understood Nico correctly, arduino is built for Arch. So I would make the java that is used for building a hard requirement and explicitly use it here for the PATH.

I think it only runs with jdk8 if it is build with jdk8, because of an incompatible change for ByteBuffer.flip() (from hazelcast#14214):

JDK9 breaks compatibility with older versions for ByteBuffer.flip() by returning ByteBuffer instead of Buffer

It happens because of this.

My default is Java 8 for other programs but arduino requires newer version because of this error and when I tried to launch arduino following this it still uses default Java version because /usr/bin/arduino adds default one to the front of the PATH.

I cannot come up with an idea to solve the problem but I think the problem lies in /usr/bin/arduino.

[NicoHood]

I tried compiling with java 11 and 15 and starting arduino with java 11 and 15, but the UI will look like this (look at the ugly java-like toolbar):

So the solution is to only allow java 8 as make and runtime dependency (and also fix the starting script to force java 8)?

But Java8 is end of life, isnt it?

[NicoHood]

I have reverted back to java8, as I saw no other solution than this.

[dimich-dmb]

Can't reproduce with OpenJDK 19.0.2