Is Processing Java?

If you’ve delved into programming-for-art before, chances are that you’ve encountered Processing. It’s a phenomenally successful tool for coding for visual art.

Processing describes itself as “a flexible software sketchbook and a language for learning how to code within the context of the visual arts”. It’s based loosely on Java, but it ships with its own development environment and code editor (the Processing “sketchbook”) and its syntax is not-quite-Java. These changes are primarily aimed at making Processing simpler and more accessible; the target audience has little to no prior programming experience. There’s no need to puzzle over the arcane incantation of public static void main(String[] args) in Processing. Instead, there’s a draw() function that somehow gets magically invoked when you run your “sketch.”

Another simplification: if you use the Processing IDE, you don’t have to deal with imports. All of the files in a given “sketch” directory are somehow available to use. This makes it easy to introduce newcomers to Processing. However, as a programmer, I want to know what’s happening under the hood.

There’s some light documentation around this (see: Is this Java? from the FAQ) but not a ton of technical detail. For a while, I was still confused – is Processing a separate programming language in its own right, or is it just Java? Can I use a normal Java IDE to write Processing, or do I need to use the Processing IDE?

As far as I can tell, Processing actually consists of three pieces:

• a Java library
• a Java pre-processor, which compiles the Processing language into normal Java
• a coding environment (the “sketchbook” / Processing IDE)

The pre-processor does some interesting things. Most dramatically, imo, it takes all of the code in a single sketch and shoves it into a single class. Any classes you declare in your .pde files are now inner classes. Also, your files will be concatenated in alphabetical order – so you can end up with e.g. conflicting definitions of variables. All of that content then gets wrapped in more boilerplate, which takes care of things like creating that nice PApplet popup window, running the drawing loop, and importing some classes like PConstants by default. This is neat on some levels (no worrying about imports! You always have access to a PApplet instance!) but can be a real headache if you need to debug something related to the pre-processor’s invisible magic.

In order to invoke the pre-processor, it seems like you need to either use the Processing IDE, or use one of the existing command-line tools like processing-java. There is also a support Python “mode” but honestly I don’t know much about how it’s implemented.

Another option is to use the standalone Java library from any other JVM environment, which means that you could use something like Kotlin, Clojure, or Scala. The tricky bit is that you’ll be missing any magic from the pre-processor or the IDE. Some considerations if you want to use Processing as a standalone library:

• You’ll need to subclass the PApplet class.
• Some of the syntax is slightly different.
• You’ll need to handle imports on your own. There are magical constants like PI that are available in Processing without needing to specify any imports; these are located in the PConstants class.
• The Processing IDE handles a lot of Java classpath issues for you. Processing uses its own version of Java, not whatever Java you have installed on your system. Also, if you want to use the Processing library you’ll need to add the core.jar file to your classpath. Processing 3.x doesn’t support Java 9 or later. It doesn’t support all Java 8 features, either.

None of these are insurmountable issues. The most difficult part is that the Processing docs all assume that you’re using the “full” Processing experience of library, pre-processor, and IDE. Luckily, the source code itself is fairly straightforward and well-commented.

Personally, now that I have a better understanding of the different abstraction layers at play, I’ve really been enjoying using Processing with Scala, using IntelliJ as my IDE and SBT for my build tool. I have a very small and poorly-tested template project demonstrating this.

Using Processing outside of the standard “sketchbook” environment means that I can use all of my usual tools. I can write tests for my code, I can organize my code into many classes and files, I can use a full-fledged IDE where I’ve already memorized the keyboard shortcuts. I like using Scala because I already use it at work, so it’s a natural language to think in. You could also use Processing from other JVM languages, like Kotlin or Clojure. As an example, Tyler Hobbs uses a Clojure library called Quil for interacting with Processing.

So, in summary – Processing isn’t Java. It’s a Java library, and some tools on top of that. If you’d rather treat it like a Java library, then as a programmer, we can do that!

Thank you to Michael Noronha and Akiva Leffert for commenting on an early draft of this post.

---