Processing in style with Java 11

@sampottinger I think I know why there is the wrong jdk in the aarch64 build, there is mismatch in naming between build.xml linux-arm64 and the linuxarm (what a crazy build system, it must be nightmare to maintain, like @neilcsmith I would highly recommend moving to maven, it is way saner). Also affects jfx install, however that only seems to be available for armv6hf.


I set up my RPi 4 with a 64-bit kernel and an SSD root drive thanks to these instructions:

After installing OpenJDK 11, and replacing the included x86-64 JDK with the arm64 version, as mentioned in previous posts, I was able to use the Processing4 build ( successfully :partying_face:

Tried out some simple sketches of mine and they ran perfectly. Awesome work!

1 Like

Got another community build at! A few more PRs are making their way in. :slight_smile:


The work you are doing is appreciated.

On a positive note…

Processing 3:

Processing 4:

It handles binary literals much better.


It’s Processing’s pre-processing which dunno about binary literals.
We can use binary literals on a “.java” tab even on P3.

1 Like

The jdk included with aarch64 release is still the wrong type as I mentioned previously but easily fixed by creating a soft link. Because I’m using Manajaro linux I just link /usr/lib/jvm/default-runtime.

[tux@monkstone ~]$ java --version
openjdk 14.0.1 2020-04-14
OpenJDK Runtime Environment (build 14.0.1+7)
OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode)

And processing runs just fine.

1 Like

Finally got round to testing ManjaroARM with my RasberryPI3B+ by using same SD card I had used on my RaspberryPI4, and it works well. Here is sketch using my LSystems library, running from processing ide on RaspberryPI3B+.


Glad to see these updates! Thanks for continuing to test this out. :smiley:

1 Like

@sampottinger What if any are the implications for processing, when macOS/AArch64 lands, it is clear that Apple have little interest in supporting java and there’s the crazy business of Microsoft offering to help to contribute to the jdk port I know Charles Nutter is keen to do what he can to support JRuby on the platform.

1 Like

Hey there! For Processing 3, it’s hard to say… Java 8 might get stuck per the conversation at That said, I would expect us to be able to keep Processing 4 afloat:

1 Like

This all looks fantastic! I can’t wait to fire up my Pi 4 and give this a try!

@sampottinger @Andres I don’t know whether it’s been solved yet, installing libraries from the ide seems to fail. However I thought I would try the latest video library on the RaspberryPI 4 (so I did a manual install. Using the GettingStarted sketch this is my output on ManjaroArm Linux (64bit)

Processing video library using GStreamer 1.18.0
[0] "bcm2835-isp #1"    
[1] "bcm2835-isp #2"
[2] "UVC Camera (046d:0825)"                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     

So [0] & [2] seem to be the V4L2 drivers, which may need additional install on Manjaro ARM as well as the camera. However from my previous experience I know [2] is my USB Camera, so for me at least I should use that (video library defaults to using 1’st in list and that does not work for me). So here’s the modified mirror sketch run from processing ide:-


Installing video library gets as far as creating a folder /home/tux/sketchbook/libraries/library10580665561486927026tmp, but fails to rename it. PS: clicking on updates available seems also to freeze ide.

Hi @monkstone and @sampottinger … Thank you for all your efforts! I make art installations and use RPIs with processing for most of them (trying as low cost as possible). With RPI 3’s phasing out I like to future proof my efforts and go RPI 4. However, as you know, the current stable Processing release doesn’t work well on a RPI 4 (I need to use P2D in full screen). This makes me want to try out your solution of running Processing 4 on RPI 4. However, not quite sure how to get started since I am not a big Linux user… seems from reading this thread, especially @monkstone guidance, the following:

  1. Install Manjaro. - or Ubuntu desktop (though that requires be to buy 4 GB models)
  2. Install @sampottinger aarch64
  3. Replace Java - how / where do you install the correct Java, or is it part of the Manjoro installation?
  4. Run Processing as usual?

Any additional pointers appreciated … Thanks so much!

@hooeef I have used the SD card from my RaspberryPI4 with Manjaro OS installed, in a RaspberryPI3B+, it works albeit a bit underwhelming, I think it is possible to do a minimal install to save space. You may need to install java see:- currently OpenJDK14 is default (which is fine).
I replace java folder (of processing install) with a symbolic link to the distro installed java to use (just link /usr/lib/jvm/default-runtime , read up on how to create a soft link on unix/linux). PS once you get used to it you may come to love Manjaro which uses Archlinux package management system rather than Debian package management (RaspberryPI OS). The 64 bit RaspberryPI OS is coming, but like a release version of Processing-4.0 it will be a longtime coming.
I am writing this addendum on my RaspberryPI3B+ using said Manjaro install (and the startup time for the processing ide is dreadful if you could avoid using ide on RaspberryPI3B+ you might get better results the ide is a resource hog).

1 Like

If you are using Sams Release like me then you’ll probably have installed it in your home directory
The actual processing will be in
/home/tux/processing4/work and the java folder will be
Delete or move that folder and replace with symbolic link as described. Once created you should be able to
ls -al in a terminal in the work directory:-
java -> /usr/lib/jvm/java-14-openjdk

or java -> /usr/lib/jvm/default-runtime where default-runtime is itself a symbolic link.

1 Like

@monkstone your guidance worked like a charm, many thanks!! I can run processing4 now and played with some of the libraries and examples. Figuring out my way around Manjaro (trying to get a virtual terminal running to the RPI 4) but should be able to give my work a go tomorrow. Thanks again!

Not sure how significant or helpful this will be / is, but I briefly tried the pre-built package ( on Ubuntu 20.04 with Unity 7.5.0 (non-standard) and a 4k screen. From my limited testing, it seemed to work fine with only minor issues.

There was an apparent DPI scaling issue on the editor menus where the text was displayed too large. The JAVA2D renderer appeared to have what I assume is the same scaling issues with dimensions not displaying as expected (but I assume that renderer is going away…?).

Screenshots below are 3 vs 4 with a 14pt editor font. The editor font in 4 seems reasonably scaled on my screen, but not the menus. The menus on 3 seem a little strange when compared to Firefox for example, but reasonably sized.



Using FX2D produced the warnings below, but it appeared to not affect the output. IE It looked like anti-aliasing worked fine.

Nov 30, 2020 9:54:56 AM javafx.scene.Scene <init>
WARNING: System can't support ConditionalFeature.SCENE3D
Nov 30, 2020 9:54:56 AM javafx.scene.Scene <init>
WARNING: System can't support antiAliasing

With P3D or P2D I still get the following spew (from JOGL I believe) when closing sketches which has been around for quite a while I think.

X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 2/2, reusable (open, marked uncloseable): 0, pending (open in creation order): 2)
X11Util: Open X11 Display Connections: 2
X11Util: Open[0]: NamedX11Display[:0, 0x7f0924001730, refCount 1, unCloseable false]
X11Util: Open[1]: NamedX11Display[:0, 0x7f09241e7d80, refCount 1, unCloseable false]

@rbrauer I have the same spew but the sketch executes okay. However I noticed that my sketch runs faster in fullScreen() - (at 18fps) than fullScreen(P2D) - (at 13fps). That was definitely not the case on a RPI 3 where I can run my sketch in P2D at 30fps. Also when running fullscreen in Manjaro, I still see the “task bar” on the bottom.

I wouldn’t be too surprised to find window issue is with unity desktop, xfce desktop works ok for me with Manjaro Arm.