Supported Platforms (original) (raw)

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:

1. macOS Sequoia 15 on Apple Silicon
2. Windows 11 (AMD) & Windows 10 (Intel)
3. Linux (Ubuntu 22.04, 64-bit Intel)
4. Linux on Raspberry Pi (64-bit ARM)

If something is broken on one of those platforms, we'll try to fix it.

Also check out the 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:

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

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