Processing on Jetson Nano

Hi. I’m working on a SBC based project using processing. After having some problems with the Raspberry Pi due to the problems of implement an on/off button in a system with a little picoprojector (, I decided to go on with a Jetson Nano hoping that I will have less problems when I execute processing sketches, because of its GPU (and hoping that it will be easier to implement an on/off button, oh my god!!!). I have decided to go on with a little picoprojector based on an HDMI connection too.
As the Jetson Nano is an ARMv8 processor rev 1 (v8l) x4 with a 64 bits ubuntu OS, do I have to install the ARM processing version or is it better to install the Linux 64 bits version?
Thanks in advance.

You definitely need an ARM version. The Linux 64 bit download is for Intel / AMD 64 bit. As far as I know the ARM 64 is fully compatible with 32 bit ARM binaries. Not sure there is an ARM 64 build of Processing available as yet? @gohai ?

1 Like

Thanks, but I downloaded the only ARM version that it’s available in the processing website and I tried to install it on my Ubuntu 18.04 Jetson Nano and it doesn’t run. I can see a “java: not found” message.

Interesting! Is there a bundled JDK inside it? Maybe it needs a system installed JDK on ARM? I’ve only ever used the Processing libraries separately from the install on ARM so I’m not the best person to answer that.

I don’t know. When I typed “java -version”, it said that there were no java installed.
I have installed java version 11, but it seems that it is not a valid version that let me run ARM Processing.
I have read in github ( that the version 8 is a valid version, but I can’t find Oracle Java 8 version anywhere. The following way to install is no longer valid:
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java8-installer

Does somebody have a solution?

I’ve found this on
" Java Versions
It’s never necessary to install Java to use Processing. Across all platforms, Processing uses its own copy of Java that’s embedded inside the application."


There should be a Java folder inside the Processing folder?

Yes, there is it.
But I can’t run processing. Here are the messages I get:
smantik@PantaNano:~/processing-3.5.3$ ./processing
smantik@PantaNano:~/processing-3.5.3$ -Djava.ext.dirs=/home/smantik/processing-3.5.3/java/lib/ext is not supported. Use -classpath instead.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Interesting! That error message suggests it’s incorrectly using your system installed Java (support for java.ext.dirs was removed in 9 IIRC). What does running ./processing-3.5.3/java/bin/java -version show you? It may be something needs tweaking in the setup because of 32-bit / 64-bit issues?!

If the launch script will only pick up the system JDK you could also install OpenJDK 8 from multiple places - I know Liberica have been really targetting ARM systems and AdoptOpenJDK also has ARM builds. Both ARM 64-bit only I think though.

Incidentally, re-reading your initial post, it’s quite easy to make an off switch for the Pi (assuming no sudo password) by using exec() to run sudo shutdown now based on some trigger.

I have installed a version of openJDK8 and it didn’t work.
After that, I tried the Liberica Linux ARMv8 64 bit 8u212 and I got the message that you can see in the image:

I clicked “Ok” and Processing welcome window appeared!!! :star_struck:
But, after closing that window, I opened some example files and it’s impossible to run them. Here are the messages that I get in the console:
Exception in thread “Thread-11” java.lang.RuntimeException: Exception while attempting /opt/processing-3.5.3/java/bin/java -agentlib:jdwp=transport=dt_socket,address=8473,server=y,suspend=y,quiet=y -Djna.nosys=true -Djava.ext.dirs=/opt/processing-3.5.3/java/lib/ext -Djava.library.path=:/opt/processing-3.5.3/core/library:/usr/java/packages/lib/aarch64:/lib:/usr/lib -cp /tmp/Esfera7451867829771913641temp:/opt/processing-3.5.3/core/library/jogl-all-natives-windows-amd64.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-windows-i586.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-linux-amd64.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-linux-amd64.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-macosx-universal.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-linux-i586.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-linux-armv6hf.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-macosx-universal.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-linux-i586.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-linux-aarch64.jar:/opt/processing-3.5.3/core/library/core.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-windows-i586.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-linux-aarch64.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-linux-armv6hf.jar:/opt/processing-3.5.3/core/library/gluegen-rt.jar:/opt/processing-3.5.3/core/library/jogl-all.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-windows-amd64.jar:/opt/processing-3.5.3/java/lib/rt.jar:/opt/processing-3.5.3/lib/ant-launcher.jar:/opt/processing-3.5.3/lib/ant.jar:/opt/processing-3.5.3/lib/jna-platform.jar:/opt/processing-3.5.3/lib/jna.jar:/opt/processing-3.5.3/lib/pde.jar:/opt/processing-3.5.3/core/library/core.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-linux-aarch64.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-linux-amd64.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-linux-armv6hf.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-linux-i586.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-macosx-universal.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-windows-amd64.jar:/opt/processing-3.5.3/core/library/gluegen-rt-natives-windows-i586.jar:/opt/processing-3.5.3/core/library/gluegen-rt.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-linux-aarch64.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-linux-amd64.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-linux-armv6hf.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-linux-i586.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-macosx-universal.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-windows-amd64.jar:/opt/processing-3.5.3/core/library/jogl-all-natives-windows-i586.jar:/opt/processing-3.5.3/core/library/jogl-all.jar:/opt/processing-3.5.3/modes/java/mode/JavaMode.jar:/opt/processing-3.5.3/modes/java/mode/antlr.jar:/opt/processing-3.5.3/modes/java/mode/classpath-explorer-1.0.jar:/opt/processing-3.5.3/modes/java/mode/ -ea processing.core.PApplet --display=-1 --sketch-path=/opt/processing-3.5.3/modes/java/examples/Demos/Performance/Esfera Esfera
at processing.core.PApplet.exec(
Caused by: Cannot run program “/opt/processing-3.5.3/java/bin/java”: error=2, No such file or directory
at java.lang.ProcessBuilder.start(
at java.lang.Runtime.exec(
at java.lang.Runtime.exec(
at processing.core.PApplet.exec(
… 2 more
Caused by: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(
at java.lang.ProcessImpl.start(
at java.lang.ProcessBuilder.start(
… 5 more


Oh, the annoying OpenJDK error message - yep, ignore that!

So, where did you get the Processing download from? Did you put it in /opt? Where is the Liberica JDK installed? If the Liberica JDK isn’t inside the Processing java folder, try deleting or renaming that. Then create a symlink called java in the Processing folder that points to the jre folder in OpenJDK.

eg. ln -s /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/ java is what I do on my machine with every Processing download, although that’s not ARM obviously.

Nice choice of example! I use Esfera as my go-to in PraxisLIVE workshops to teach people how to convert sketches! :smile:

I downloaded Processing from:

I put it in /opt

Liberica JDK was installed in /usr/java folder. I have uninstalled it and deleted the folder that was in /usr/java.
I have downloaded again the Liberica JDK for ARM 64 bits and moved the .deb file to the /opt/Processing-3.5.3/java folder and installed it from there.
Then, I create a symlink (I don’t know exactly what it is) writing in the terminal (from the /opt/Processing-3.5.3 folder):
sudo ln -s /usr/lib/jvm/bellsoft-java8-aarch64/jre java
I run Processing and the window that alerts me from OpenJDK persists. I load an example sketch and I can’t run it as before.
There is the same line as before in the error console:
Cannot run program “/opt/processing-3.5.3/java/bin/java”: error=2, No such file or directory

Somebody told me about this site for installing JDK 8:

I followed instructions and get lost.
I typed:
sudo apt-key adv --keyserver hkp:// --recv-keys 0xB1998361219BD9C9 * * sudo apt-add-repository ‘deb stable main’
and I get a list
$ sudo apt-get update
and suddenly appears:
Hit:12 bionic InRelease

After that, they ask me to install Zulu. I read the instructions and I think it’s another OpenJDK Java version (I thought it was the original Java Oracle 8 version).

I’m really lost and my head starts to spin

In other forum, simon-ritter posted a valid solution. I share it here because it can be useful for somebody:

OK, I got my Jetson Nano yesterday and have resolved the issue of getting Processing working.
1. Download the Zulu JDK from here:
You need a 64-bit Arm build. I used the JDK 8 one for simplicity.
Untar the download using tar -xvf zulu8.38.0.162-ca-jdk1.8.0_212-linux_aarch64.tar.gz
2. In the Processing directory, there is a java sub-directory. Remove this or move it to something like java-bad.
3. Copy the untared zulu8 directory to the processing directory and rename it java
4. Run processing. It will whinge about it not being an Oracle JDK but that doesn’t matter, Processing will now work.


Glad you got it working. This is basically identical to what I suggested above though :confused: (symlink appears as a folder to Processing) so something awry in the setup. Be interested how well it performs - I’m thinking of getting one myself for remote embedded work with PraxisLIVE.

1 Like

I tried to create the symlink as you said and it didn’t work for me. It is possible that I did something wrong.
I was testing this morning with some example sketches and the “performance examples” are not running due to a “fatal error” detected by the Java Runtime Environment. (“Failed to write core dump. Core dumps have been disabled”).
With some other easier examples I have some delay in fps. I have to test some other sketches.

It’s something curious that the error only appears in those sketches that has P2D or P3D in size!!! In other words, those sketches that utilize OpenGL and not with the default renderer (this ones can run).
I have tested OpenGL with glmark2 in my system and it works perfectly. In fact, it shows a great score in glmark2 test and animations are running so smothly!
What can be the reason of that?

Do you get a hs_err_<pid>.log file anywhere? I’d guess this is a segfault in JOGL somewhere. If so, that file should have the native function that’s crashing in it.

Yes, I get a hs_error_pid.log file everytime.

This is what Processing texts:
A fatal error has been detected by the Java Runtime Environment:

  • SIGSEGV (0xb) at pc=0x0000007f94fcb670, pid=7155, tid=0x0000007fad4091f0*

JRE version: OpenJDK Runtime Environment (8.0_212-b162) (build 1.8.0_212-b162)
Java VM: OpenJDK 64-Bit Server VM (25.212-b162 mixed mode, Evaluation linux-aarch64 compressed oops)

  • Problematic frame:*
  • C []*

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try “ulimit -c unlimited” before starting Java again

An error report file with more information is saved as:

If you would like to submit a bug report, please visit:

Could not run the sketch (Target VM failed to initialize).
For more information, read revisions.txt and Help → Troubleshooting.