Clone this wiki locally
This page describes our relationship to Mac OS X, Windows, and GNU/Linux. Scroll to the bottom, and you can even read about different versions of Java.
The Processing Development Environment (PDE) is currently tested on:
- Mac OS X 10.11 (and a little 10.9, but not much 10.10 anymore)
- Windows 7 (32-bit and 64-bit)
- Ubuntu Linux 14.04 (64-bit)
- Windows 10 (maybe 8.1 if we have to)
- Ubuntu Linux 12.04 (32-bit)
This list is in order of what gets the most testing, with primary development happening on OS X. 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. 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 is generally the the best platform for running Java applications. It's not because we like Windows (we don't) but that's just how it is.
We are not supporting or testing with Windows Vista. We went straight from Windows XP to Windows 7.
We do a bit of testing on Windows 10, because Microsoft seems to have fiddled with things in ways that sometimes break Processing.
Very little testing happens on Windows 8. When we do, we only use the latest version (8.1).
Recent Server editions of Windows are not supported, but are reported to work.
Mac OS X
Java on Mac OS X has always dragged behind other platforms.
As of Processing 3.0, OS X 10.11 receives the most testing. If you're using an earlier version, you should consider upgrading because even Apple is aggressively dropping support for earlier versions.
Mac OS X 10.8.5 or later is required to run Processing 3. Mac OS X 10.9+ is recommended. A 64-bit machine is also necessary.
Processing 2 was the last version to support OS X 10.7.
Starting with Processing 2.1, we are no longer using Apple's (deprecated) version of Java and have switched to the Oracle release. This means:
- Processing is only 64-bit on OS X, because Oracle's Java only supports 64-bit machines.
- There will be bumps in the transition. Help me fix them.
- The download size is larger, because an entire JRE has to be embedded.
- There are some performance losses with graphics because the graphics engine in Oracle's version isn't optimized as well as Apple's was. There's a lot of work in Processing 3 to address these issues, including better OpenGL support and the new
FX2Drenderer. Those might be an option if you're having performance problems.
Apple has long since discontinued support for their version of Java that was used on older versions of Processing. In fact, it won't even be available in future versions of OS X. As such, it's especially important to move things from Processing 1.x and 2.x up to 3.0. More information, straight from the horse's mouth:
OS X v10.11 is the last major release of OS X that will support the previously deprecated Java 6 runtime and tools provided by Apple. Applications or features that depend upon Java 6 may not function properly or will not launch when Java 6 is removed.
The key conventions in Processing are closer to other programmer's editors on OS X (TextWrangler, Eclipse, etc) than other OS X 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
For Processing 3, use the
pixelDensity() command to enable super-crisp rendering on retina displays. See here for the reference.
With any luck, the Linux release should work fine by simply changing to the processing folder and typing
On Linux, the Processing application is just a shell script. If you set up a launcher (e.g. in Ubuntu), be sure to set the working directory to the folder that contains the shell script. It's not smart enough to find its own path. (If you can write a version that's smarter, please let us know).
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 the JRE 7. You can also symlink it to a JRE 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.
If you replace the 'java' folder, you'll lose the default fonts used for the PDE. You can get them back by copying the “SourceCode” items from the included java/lib/fonts folder to your new java/lib/fonts.
Due to incompatibilities, OpenJDK is not supported. You'll need a regular Java release downloaded from Sun/Oracle. The GNU Classpath, GCJ, GIJ combination will not work with Processing. OpenJDK and IcedTea also have problems, particularly with running sketches full screen or with multiple displays or even window sizing. Bottom line: use the version from Oracle.
If you get Processing to run properly, the Sketch → Show Sketch Folder command may not be available. Processing will attempt to find kde-open and gnome-open, and if neither 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
For new devices, please start a new page:
The experimental FX2D renderer is not supported on ARM, because Oracle dropped support for JavaFX on ARM devices with Java 8u33. We might want to try using OpenJFX project in the future, but as of now this is unsupported.
Most libraries from the Contribution Manager work just fine without any change necessary to run on ARM. Exception to this are libraries that comes with parts written in "native code", which is platform- and architecture-dependent, and hence needs updating. As a general rule of thumb: if you find (sub-) directories for different platforms inside the library's
library directory, then this is likely the case.
If you come across a library that's not working, or if you need help compiling a library for ARM, please open an issue.
A test version of Open Kinect for Processing, with support for armv6hf, can be found here. (PR #1 #2) On most ARM devices this will only work (if at all) with the Kinect 1, because of the high demand on USB throughput of the Kinect 2. Don't forget to place the file 51-kinect.rules in
/etc/udev/rules.d for Processing to be able to access the Kinect's camera.
Library: Simple Touch
The simpletouch library makes it possible to use any multi-touch-enabled display or trackpad with Processing, as long as the device is supported by the Linux kernel. This library is available through the Contribution Manager under the name "Simple Touch".
The two example sketches the library comes with explain how to use it. Please file issues here.
Processing is designed (and supported) to run on Oracle Java. The tar-ball comes with a recent version of Oracle's runtime for hard-float ARMv6 (and higher) architectures.
Because Processing is written in Java, it should run on any platform that supports Java 8. If you'd like to get it running on BSD, Irix, AmigaOS, BeOS... whatever, do the following:
- Download the Linux version, and replace the “java” folder with versions that support your platform. (See the Linux instructions about linking to a proper JDK).
- Next, mess with the shell script if necessary to get things up and running.
- If you have success, share the details for others.
Users of OpenBSD can use the ports and packages framework to install Processing using the following command:
Please note this package is not created by the Processing team and any possible issues should initially be reported to the package maintainer.
Across all platforms, Processing has its own copy of Java embedded, so it's never necessary to install Java to use Processing.
We don't yet support any of the Java 7 and Java 8 language features. Please help us fix this. Advanced users (loosely defined as “people who know that these features exist”) can always make use of Java 7 and 8 features from another IDE.
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.
Processing 3 uses Java 8. As of April 2015, Oracle is no longer fixing bugs in Java 7, so we had to make the switch.