# Choice of OpenJDK is Critical

**URL:** <https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141>\
**Category:** Processing\
**Created:** [December 5, 2019, 7:22am UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141 "2019-12-05T07:22:59Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![monkstone](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/monkstone/32/64_2.png) [@monkstone](https://discourse.processing.org/u/monkstone)\
**Post date:** [December 5, 2019, 7:22am UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/1 "2019-12-05T07:22:59Z")

</div>

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](https://github.com/processing/processing-video/releases/tag/r6-v2.0-beta4) 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.

---

<div class="post-metadata">

**Author:** ![neilcsmith](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/neilcsmith/32/144_2.png) [@neilcsmith](https://discourse.processing.org/u/neilcsmith)\
**Post date:** [December 5, 2019, 2:26pm UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/2 "2019-12-05T14:26:02Z")

</div>

> [@monkstone](#):
>
> 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)

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.

> [@monkstone](#):
>
> On the RaspberryPI AdoptOpenJDK is close to useless (it uses zero vm and performance is glacial)

That’s odd! Wonder why that is. Out of interest, have you tried [Liberica](https://bell-sw.com/) here?

> [@monkstone](#):
>
> 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 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.

---

<div class="post-metadata">

**Author:** ![monkstone](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/monkstone/32/64_2.png) [@monkstone](https://discourse.processing.org/u/monkstone)\
**Post date:** [December 5, 2019, 5:08pm UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/3 "2019-12-05T17:08:22Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![monkstone](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/monkstone/32/64_2.png) [@monkstone](https://discourse.processing.org/u/monkstone)\
**Post date:** [December 5, 2019, 7:57pm UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/4 "2019-12-05T19:57:30Z")

</div>

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](https://github.com/sgothel/jogl) that could change all that.

---

<div class="post-metadata">

**Author:** ![monkstone](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/monkstone/32/64_2.png) [@monkstone](https://discourse.processing.org/u/monkstone)\
**Post date:** [December 6, 2019, 7:16am UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/5 "2019-12-06T07:16:33Z")

</div>

Archlinux just updated [java-common](https://www.archlinux.org/packages/extra/any/java-common/), so on a hunch I used:-

```bash
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:-

```bash
Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!

```

---

<div class="post-metadata">

**Author:** ![neilcsmith](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/neilcsmith/32/144_2.png) [@neilcsmith](https://discourse.processing.org/u/neilcsmith)\
**Post date:** [December 8, 2019, 10:50am UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/6 "2019-12-08T10:50:09Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![monkstone](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/monkstone/32/64_2.png) [@monkstone](https://discourse.processing.org/u/monkstone)\
**Post date:** [April 7, 2020, 7:22pm UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/7 "2020-04-07T19:22:00Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![neilcsmith](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/neilcsmith/32/144_2.png) [@neilcsmith](https://discourse.processing.org/u/neilcsmith)\
**Post date:** [April 7, 2020, 7:45pm UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/8 "2020-04-07T19:45:22Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![monkstone](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/monkstone/32/64_2.png) [@monkstone](https://discourse.processing.org/u/monkstone)\
**Post date:** [January 11, 2021, 11:31am UTC](https://discourse.processing.org/t/choice-of-openjdk-is-critical/16141/9 "2021-01-11T11:31:16Z")

</div>

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.