I thought it might be worth recording my experience here of trying different versions of OpenJDK with my ruby-processing projects (I am sure same would apply to non-ide user of processing). My experience is limited to 64 bit linux and 32 bit RaspberryPI, but I expect story on MacOS and Windows would be same as 64 bit linux.
Stock OpenJDK (Archlinux and Debian 64 bit) does not work with OpenGL sketches.
AdoptOpenJDK works well with all sketches on 64 bit linux (as does Oracle)
On the RaspberryPI AdoptOpenJDK is close to useless (it uses zero vm and performance is glacial)
Stock OpenJDK8 works well, and has similar performance to Oracle jdk.
The latest beta version of the video library works fine on 64 bit linux and the RaspberryPI, except capture does not work yet with RaspberryPI4 but works well with RaspberryPI3B+. One caveat is that in my experience with USB camera is that you have to be quite specific about the camera in use, it is not sufficient to to call it by name.
The capture problem with RaspberryPI4 might be transitory as the light comes on on camera, just no video stream.
3 Likes
Didn’t realise this affects Arch too. Wonder what’s going on here? Debian OpenJDK 11 appears to have a few issues. Mind you their packaging of other Java things doesn’t fill me with confidence.
Downside of AdoptOpenJDK might be on the audio side - no PulseAudio backend.
That’s odd! Wonder why that is. Out of interest, have you tried Liberica here?
The whole approach with names in the video library is off in my opinion. Better to use the support for custom pipeline source probably. I’m also investigating looking up devices in /dev/v4l/by-id as part of a client project at the moment.
Re Liberica on PI I think I tried it on 64 bit (Arch-PI) on raspberrypi4 and it was equally glacially slow. There were many other issues with Arch-PI and the raspbian distro shines in comparison.
I only tried AdoptOpenJDK on raspberrypi to see if it worked, I think it is best to stick with jdk installed from the raspbian distribution since it works rather well, and it is unlikely anyone will do a better job. Regarding RaspberryPI4 it is still in a state of flux (the developers are still updating the eeproms). Looking up devices in /dev/v4l/by-id would be good.
Of course these comments apply to the way things stand at present (including Sam Pottingers work), but things seem to be afoot with jogl development that could change all that.
Archlinux just updated java-common, so on a hunch I used:-
sudo archlinux-java set java-13-openjdk # default
To set java environment as you do on Archlinux and the linkage problem with opengl sketches seemed to go away. However what I forgot is that I had set JAVA_HOME to /opt/jdk13 adopt-openjdk, when I set it to the Archlinux installed version I got the same linker error as before with opengl sketches:-
Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!
That error message is fairly common, and not just with JOGL - saw references to Eclipse too. Tried running from CLI with LD_DEBUG=all. Lot of output! But it seems to be problems linking with the AWT native library.
@neilcsmith Interestingly I just tried the latest openJ9 (downloaded from AdoptOpenJDK) jdk14 and it seems to work very well for me, don’t know whether it has a PulseAudio backend.
AFAIK the PulseAudio backend is GPL without classpath exception so unlikely any non-distro JDK ships with it. But you can probably install it with a bit of work.
OpenJ9 is great - had been running PraxisLIVE and NetBeans with it, although had some issues with debugging so moved back for now.
Update it seems latest OpenJDK 64-Bit Server VM 15.0.1+9 on 15.0.1+9 +jit [linux-x86_64] on Archlinux is OK, I haven’t checked to see if a fix has backported to earlier JDK releases.