Supported Platforms

This page describes how Processing works on the different platforms we support across macOS, Windows, and Linux.

The Processing Development Environment (PDE) is currently tested on:

macOS 10.15.7 (Catalina), 11 (Big Sur), and 12 (Monterey) on Intel hardware
macOS 12 (Monterey) on Apple Silicon – We're now shipping an Apple Silicon version as of 4.0 beta 8!
Windows 10 (64-bit Intel) – support for Windows 7 ended in 2018. Most people would like to forget about Windows 8. We are not currently (as of 5 August 2022) testing on Windows 11 and therefore cannot exactly recommend it, but it should work fine.
Linux (Ubuntu 22.04, 64-bit Intel) – If you're using a different Linux (or different window manager), please help us make improvements so that it runs on your platform of choice. We just can't do everything.
Linux on Raspberry Pi (32-bit ARM) – We don't currently have a maintainer, but we're doing releases. This is the only 32-bit platform that is supported with Processing 4.
Linux on Raspberry Pi (64-bit ARM) – Not a ton of people are 64-bit with their RPi devices yet, but releases are happening.

If something is broken on one of those platforms, we'll try to fix it. Most of the cross-platform work is done from a certain developer's laptop that has seven or eight VMware images to deal with all this mess. As of August 2022, that developer spends most of their time using macOS on Apple Silicon, followed by macOS on Intel and several Linux linux versions across ARM and Intel. Windows, not so much.

Things that can't be tested from a VM are run from machines at the Processing Release Testing And Quality Assurance Center (the PRTAQAC, which is currently a number of machines laying about Fathom's studio).

Also check out the Troubleshooting page for platform-specific issues.

Windows

Windows has traditionally been the best/most supported platform for running Java applications. Nowadays, there's more parity between Windows, macOS, and Linux releases.

macOS

Apple has aggressively updated their OS and deprecated old features. Older versions of Processing (3.x and earlier) are likely to not work at all, due to Apple's updates and restrictions. Please use 4.0!

Chasing Apple – Apple is upgrading the OS once a year, and we are forced to chase them. Major OS releases are supported by Apple for just 3 years, and we simply cannot support them any longer than that ourselves. Note that we only support the most recent point release for older versions. So get those Catalina machines upgraded to 10.15.7!

Home and End Keys – The key conventions in Processing are closer to other programmer's editors on macOS (BBEdit, Eclipse, etc) than other macOS defaults. This makes some people unhappy. Those people can manually edit preferences.txt (its location is listed in the Preferences window) to change a line or two:

  # The home and end keys should only travel to the start/end of the current line.
  # The OS X HI Guidelines say that home/end are relative to the document.
  # if this is not to your liking, this is the preference to change:
  editor.keys.home_and_end_travel_far = false

  # The home and end keys move to the first/last non-whitespace character, 
  # and move to the actual start/end when pressed a second time. 
  # Note that this only works if editor.keys.home_and_end_travel_far is false.
  editor.keys.home_and_end_travel_smart = true

Linux

With any luck, the Linux release should work fine by simply changing to the processing folder and typing:

./processing

Java – Most problems on Linux come from the version of Java that's included in the download being incompatible with the OS. In that case, remove (or rename) the included ‘java’ folder, and replace it with a usable version of Java 17. You can also symlink it to a JDK that's installed on your machine. Be sure that the symlink is set up relative to the processing shell script such that ./java/bin/java points to the java binary. Take a look at the folder structure of the included java folder to see how it works.
OpenJDK – Previous releases (3.x and earlier) did not work properly with OpenJDK. However, the 4.0 releases are all OpenJDK.
Show Sketch Folder – If you get Processing to run properly, the Sketch → Show Sketch Folder command may not be available. Processing will attempt to find xdg-open, kde-open, and gnome-open, and if none is available, the menu item will be dimmed. To fix this, you must set a launcher for your platform. Add a line to ~/.processing/preferences.txt that specifies its location:
```
  launcher.linux = /path/to/launcher_app
```

Java

Versions – Processing 4 supports Java 17, which is a “Long Term Support” release. We have no plans to support any other releases. If you install something older, code may not run. If you install something newer, you're on your own.
Installing Java – Don't. It is simply never necessary to install Java to use the Processing downloads for a supported platform. Processing uses its own copy of Java that's embedded inside the application.
Language Features – Since our upgrade to Java 17, we have not caught up with support for language features introduced since Java 8. If you run across something missing, you can file an issue. Existing issues will be filed under the preprocessor tag.
Reinstalling Java – People often reinstall Java when they have problems with Processing. Even though it may make you feel better, reinstalling won't help anything, because Java doesn't need to be installed in the first place.

Native Libraries

4.0 beta 4 includes several updates to how different operating systems and hardware are handled. This allows us to add Apple Silicon (M1) support, and also better handles other devices like the Raspberry Pi.

We use a naming system that defines a “variant,” which consists of the OS name (windows, macos, or linux) followed by a the naming from the os.arch value returned by System.getProperty(). Because those names can vary across JDK implementations, we'll be using the name used by the JDK included with the Processing download, which is currently from Adoptium.

This {name}-{arch} naming style helps drastically simplify the code inside the PDE, and also gets us out of the business of deciding how to rename each platform. While the naming is sometimes awkward (i.e. macos-x86_64), the alternatives are inelegant as well, so we'll err on the side of simplicity by inheriting how the platform handles naming. Users will (should) never see those awkward names! And only Library developers that need additional native code will need to understand the naming, but they should already be somewhat familiar with that nomenclature if they're working with native code.

As a result of these changes, the subfolders used to identify native libraries for each platform are different. Any library that used the old naming convention (macosx, windows64, etc) correctly will still work. But use these new names so that your library is ready for other platforms like Apple Silicon, or ARM on the Raspberry Pi.

Hardware/OS	`os.arch`	bits	4.0 library folder	old library folder	download suffix
macOS (Apple Silicon)	aarch64	64	macos-aarch64	—	macos-aarch64
macOS (Intel 64-bit)	x86_64	64	macos-x86_64	macosx	macos-x64
Windows (Intel 64-bit)	amd64	64	windows-amd64	windows64	windows-x64
Linux (Intel 64-bit)	amd64	64	linux-amd64	linux64	linux-x64
Linux (Raspberry Pi 32-bit)	arm	32	linux-arm	linux-armv6hf	linux-arm32
Linux (Raspberry Pi 64-bit)	aarch64	64	linux-aarch64	linux-arm64	linux-arm64

(The “bits” column is equivalent to sun.arch.data.model)

Raspberry Pi vs Linux – Technically, the Raspberry Pi releases may run on other ARM Linux installations, but they aren't tested that way. And the Raspberry Pi version includes additional libraries that are specific to the Pi. Put another way, generic Linux on ARM is not a supported platform, so we don't list it as “Linux (ARM 32-bit)” in places like Export to Application.

Old Libraries – Some libraries did not properly use the old naming system, which will cause them to break in the 4.0 release. For instance, if dylib and dll files were simply placed in the root of a library, the library will probably not work. Moving the files into subfolders that use the naming conventions above should get them working again. If this sounds confusing, just look at how the core folder is laid out in the Processing software itself: it's a single library with native libraries for all six platforms to support OpenGL .

Native Libraries for Some Platforms, Not Others – If your library only needs native code on certain platforms, create the subfolders for the other platforms anyway, and simply leave the folders empty. Otherwise it will appear as though the native libraries are “missing” for their machine, and the user will be shown a warning. This is an exceptionally rare scenario, but it happens.

You can also view the Supported Platforms from 3.x, though much of that information will be out of date.

Provide feedback

Saved searches