Inside processing4: the core library, the PDE and the 5.0 branch

main carries 5.0 work while 4.x collects the fixes

The first thing this repository tells a contributor is that the default branch is not where bug fixes go. A note at the top of the README states that Processing 5.0 development is underway on `main`, that new features and 5.0 work should target `main`, and that bug fixes for Processing 4 should be opened against the `4.x` branch. That split matters more than it first appears, because a patch aimed at the wrong branch is a patch against an API that is still moving.

The tagged releases show the same two-track story in practice. The most recent builds are 4.5.7 and two release candidates for it, dated 2026-09-15, 2026-09-18 and 2026-09-24. The last push to the repository was on 2026-09-25, one day after the final release, so the tree reflects work done around the 4.5.7 line rather than an idle copy.

If you are unsure which branch to target, the README gives a concrete place to ask: the issue thread, or Discord in #devs-chat. It also keeps processing4 open for outside contributors by pointing them at CONTRIBUTING.md and the Discord server rather than at a mailing list.

The tree separates core, app, libprocessing and build tooling

The repository description says this holds the source for Processing, the sketchbook and Java-based programming language used by students, artists, designers, educators, hobbyists and creative coders, and that it includes the core library and the editor (PDE). The top level of the tree backs that up with separate directories for `core/`, `app/`, `libprocessing/` and `java/`, alongside `build/`, `buildSrc/` and `utils/`.

The build side of the tree is Gradle based. The root contains `build.gradle.kts`, `settings.gradle.kts` and `gradle.properties`, plus both `gradlew` and `gradlew.bat`, so the wrapper ships with the project rather than expecting a system-wide Gradle install. There is also a `gradle/` directory for the wrapper configuration itself and an `SCHEMA.md` file whose purpose the README does not explain.

Editor configuration is checked in as well. The `.idea/` directory is part of the tracked content, which is consistent with the README's instruction to open the project in IntelliJ IDEA rather than in a generic Java IDE. Whether you want a shared IDE setup is your call, but the project clearly treats that directory as part of the build path rather than as a local scratch file.

A handful of governance documents sit next to the code: AGENTS.md, AI_USAGE_POLICY.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, CONTRIBUTORS.md and LICENSE.md. For a code host, that is a fairly complete trail of the rules a contributor is expected to follow, even though the README itself stays short on technical detail.

Building locally means IntelliJ IDEA, a Gradle sync and one run configuration

The README gives a five step quick start for building Processing on your own machine, and the stated reason for doing it is troubleshooting: to confirm that your contribution works as intended before submitting it, and to get a feel for how the project is structured.

The steps are simple enough to follow without prior knowledge of the build:

1. Fork and clone the repository
1. Open it in IntelliJ IDEA
1. Wait for Gradle to sync
1. Hit Run

One step is described in prose rather than in the list: next to the run button you select the `Processing` configuration, which is the entry point the IDE offers for this project. The README sends anyone who wants more detail to the How to Build Processing guide in BUILD.md.

There is no package manager command, no install script and no published artifact recipe in this documentation, and the quick start is written for a contributor who already has the repository cloned. That is the honest shape of this build guide: it is a contributor entry point, not a distribution pipeline.

If you only want to use Processing, this repository is the wrong door

The README is unusually clear about the boundary between using the language and improving it. For people who want to use Processing, it directs them to the download page and to the project website, and it points at the tutorials and at the hundreds of examples bundled with the software itself. The repository exists, in the project's own words, for people who want to help improve the code.

That framing also sets expectations about the audience. Contributors are the target, not students. The README spends most of its space on how to raise a pull request, where to ask questions, how to behave on the forum, and how the project handles contributions from newcomers. It explicitly says it does not assume knowledge of any particular thing, which is a reasonable stance for a project that welcomes contributions from a wide range of people.

Support requests are routed to the forum at discourse.processing.org, and the README asks readers to check the guidelines on asking questions before posting, so that questions arrive with enough context to be answered. Bug reports and feature requests are meant to go into the GitHub issue tracker instead. Technical support and bug reports therefore live in two different places, and knowing which one to use is the first practical thing a newcomer has to decide.

Three licences cover one codebase, and the licence classifier cannot name them

Processing ships under a layered licence arrangement, and GitHub reflects this by reporting the repository as using a custom licence that it cannot classify. The README then spells out the layering.

The core library is licensed under the GNU Lesser General Public License version 2.1. Everything else, including the PDE, is under the GNU General Public License version 2. The reference material, including the JavaDoc comments, is under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International licence. Complete details are in LICENSE.md, and the website has its own separate licensing terms in a different repository.

The practical shape of this is that the layer you reuse determines which obligations you inherit. Code that builds on the core library sits under the LGPL terms, while changes to the editor fall under the GPL terms, which carry copyleft conditions on distributed derivatives. The reference and its documentation carry an attribution requirement along with noncommercial and share-alike conditions. None of that is legal advice, and none of it should be, but it is enough to say that the answer to the question depends on which directory you are working in. Copyright in the tree is held by The Processing Foundation from 2015 onward.

Fully generated patches are turned away by the project policy

The repository carries an AI usage policy, and it is stricter than most. The README states that the project does not accept fully AI-generated contributions, that AI tools may be used assistively only, and that a contributor should be able to understand and take responsibility for the changes made to the codebase. Further details are pointed at AI_USAGE_POLICY.md and AGENTS.md.

For a project that has spent more than two decades accumulating contributions, this is a defensible position, and it has an obvious effect on how you prepare a patch. Work that a person cannot explain is work that a maintainer cannot merge, so reading the two policy files before writing code is not a formality.

The rest of the contribution rules follow a similar tone. The project maintains a code of conduct with zero tolerance for harassment or toxic behaviour, while still offering newcomers explicit encouragement to reply to issues, review pull requests or help out. A CONTRIBUTORS.md file and the all-contributors specification record who has worked on the code and how contribution types are labelled. The project also credits its originators, noting that Processing was initiated in 2001 by Ben Fry and Casey Reas, who led development until 2023.

Building from source versus downloading the packaged editor

The realistic alternative to this repository is the packaged editor, and the two approaches differ in more than effort. The download page gives a working environment with the core library, the PDE, the bundled examples and the tutorials already in place, with no Gradle sync and no run configuration to select. Nothing in the sketchbook workflow changes.

Building from source is the option that opens things the packaged editor does not: reading the implementation of the core library, patching a behaviour, running the code under your own toolchain, and testing a fix before a pull request exists. The cost is the environment. IntelliJ IDEA is expected, the Gradle sync has to complete, and the `Processing` run configuration has to be selected by hand before anything executes.

The two branches make a third choice necessary. If the bug you care about exists in 4.x, the fix belongs on the `4.x` branch, not on `main`, where 5.0 work is landing and where the API surface may already have moved. A contributor testing against `main` while shipping a 4.x fix is validating the wrong line of the language, and the release tags from September 2026 show both lines are active at once.

Editorial conclusion

processing4 suits Java developers who intend to read, patch or build the Processing core library and editor, and suits educators who want to teach from the actual implementation. It does not suit people who want to make artwork, since the ready-to-run editor comes from the download page rather than this tree. Before you commit, check which branch your change belongs on, read AI_USAGE_POLICY.md before preparing a patch, and confirm that the LGPL and GPL split fits what you intend to do with the code.

Frequently asked questions

Official sources

1. Issues
2. processing/processing4 on GitHub
3. Project website
4. README
5. Releases