Integration of Processing into Ubuntu

Processing
1

I tried to install Processing 4.4.4 on Ubuntu 24.04 (latest version at time of writing). The only option seems to be via a snap. However, the integration into Ubuntu is poor: on startup, I regularly see exceptions (attached), and it is impossible to associate .pde files to be opened with processing. Also dragging a .pde file into the processing window will only open that simngle file, even if it’s part of a bigger project … trying to run it, will subsequently complain about missing files.

I can only speculate that it’s due to the snap’s strict confinement? In any case: How to get a working and USABLE processing inmstallation on Ubuntu, in particular if you are a beginner (like my students).

These are the exceptions generated when starting processing:

Jun 17, 2025 6:02:02 PM java.util.prefs.FileSystemPreferences$1 run
WARNING: Couldn’t create user preferences directory. User preferences are unusable.
Jun 17, 2025 6:02:02 PM java.util.prefs.FileSystemPreferences$1 run
WARNING: java.io.IOException: No such file or directory
java.lang.reflect.InaccessibleObjectException: Unable to make field private static java.lang.String sun.awt.X11.XToolkit.awtAppClassName accessible: module java.desktop does not “opens sun.awt.X11” to unnamed module @4aae4e96

And these repeat every 30 sec while processing is running:
Jun 17, 2025 6:02:34 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 2.
Jun 17, 2025 6:02:34 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.
Jun 17, 2025 6:03:04 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 2.
Jun 17, 2025 6:03:04 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.
Jun 17, 2025 6:03:34 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 2.
Jun 17, 2025 6:03:34 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.
Jun 17, 2025 6:04:04 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 2.
Jun 17, 2025 6:04:04 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.
Jun 17, 2025 6:04:34 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 2.
Jun 17, 2025 6:04:34 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.
Jun 17, 2025 6:05:04 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 2.
Jun 17, 2025 6:05:04 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.
Jun 17, 2025 6:05:34 PM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 2.
Jun 17, 2025 6:05:34 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn’t flush user prefs: java.util.prefs.BackingStoreException: Couldn’t get file lock.

1 Like
2

Same here!!!
Yet another problem: libraries won’t install properly.

https://discourse.processing.org/t/can-t-install-libraries-after-starting-using-processing-in-snap/46557?u=rbgtoffolo

I’ve followed all the suggested Snap troubleshooting steps, including:

1 - Connecting the home interface:
sudo snap connect processing:home :home

  1. Installing Processing in classic mode:

sudo snap install processing --classic

  1. Creating the sketchbook folder manually:

mkdir -p ~/snap/processing/current/sketchbook/libraries

However, I’m still experiencing issues with library installation. The Processing IDE either fails to install libraries or can’t detect them after installation.

1 Like
3

Even if there are (complicated) workarounds, that’s not a good state for what used to be an easy to use (and install) IDE for beginners :frowning:

1 Like
4

So Processing has indeed stopped providing actual downloadable builds for Linux and Raspberry Pi; while keeping them for Windows and MacOS!

The “replacement” choice “snap” is a mistake, b/c either a distro bans this distribution package format, for example Mint which favors “flatpak” & disallows “snap”; or it’s not trivial to install & config, like on Arch-based distros!

Apart from Ubuntu and Zorin OS, very few other distros are configured to use “snap” out-of-the-box on their software manager!

“Flatpak” is the most universal delivery package for Linux.

“AppImage” format is also a much better choice than “snap”.

2 Likes
5

Hi all, and thanks to everyone who’s taken the time to report issues and share feedback around Linux distribution. It’s clear that the current setup is causing frustration and we want to be transparent about how we got here, and what we’re doing next. Please excuse the long post.

tl;dr: We’re working on switching to classic confinement first, then adding a Flathub release. Input and help are welcome.

In March, we migrated from Ant to Gradle. This was a necessary step to reduce technical debt, improve the developer experience, and make it easier for others to contribute to Processing.

However, switching build systems meant we had to drop the old custom packaging scripts, which weren’t sustainable to maintain and didn’t align with how most Java software is distributed. From a technical perspective, this custom install process made future development much harder. From a user perspective, it led to a confusing experience on Linux, especially for people new to the platform, with downloads often just being unzipped and run in-place, without installation or integration into the system.

With the new Gradle-based build, we wanted to lean on existing packaging tools rather than rebuild the same ad-hoc setup from before. On Windows and macOS, this transition was smoother: we now offer signed .msi and .dmg installers with good integration into the OS. On Linux, things are more fragmented, and there’s no clear standard. We chose a packaging format that offered broad compatibility, automatic updates, and a streamlined release process. This is particularly helpful for users who aren’t experienced with Linux.

Snap’s containment features seemed like a good way to offer a more secure binary, so we initially opted in. In hindsight, that choice introduced more restrictions than expected for Processing’s typical use cases, particularly in education or when using serial devices, custom libraries, or sketches that expect full file access.

Changing how Processing is distributed on Linux wasn’t part of the original plan, and we definitely didn’t intend to introduce this kind of friction. Our main goal was to modernize the build system while keeping most of the user experience unchanged. Clearly, we got some things wrong, and we really appreciate your feedback.

Here is how we’re planning to address these issues:

  1. Switch to classic confinement. This is the most straightforward way to address the regressions caused by the current sandboxing.

  2. In parallel, we’ve also been working on a Flathub release. Having both Snap and Flathub available would help us support a wider range of Linux users.

We’d love your feedback on this approach: do you use Flathub? Would it be your preferred install method?

We’re not excluding the possibility of releasing an AppImage as well if there is interest in it. We looked into it earlier, and it seemed incompatible with our current build setup, but we’ll take another look and see if those issues can be addressed.

We know the current situation isn’t ideal, and we appreciate your patience while we work on making Processing easier to install and use across Linux distributions.

Side note: if you prefer an experience closer to how Processing was previously distributed, you can find portable builds on the GitHub releases page.

If you have ideas, packaging experience, or time to help test upcoming builds, please let us know. We’ve also made it much easier to build Processing from source for those who want to get hands-on with the codebase or contribute directly.

Thanks again for helping us make Processing better.

Cheers!
@stefterv & @sableraph

2 Likes
6

Automatic update is a form a malware. It makes changes to your system without your knowledge or consent. Even if all you think it’s doing is making “fixes” to “bugs”, users’ code may well have work-arounds or even depend on those “bugs” to produce the specific output they want.

Any installation method for Processing should allow for multiple installed versions, letting users test new versions on their old code before fully committing to a switch, and/or should allow an easy roll-back to an older version.

Snap is a proprietary format under control of a private company and many Linux distributions refuse to work with it. If you want to support the widest range of Linux users, please still provide .tar.gz files with the same install script that Processing has had for years. The install script worked well, supported multiple version installs, and made it easy to switch between them. And include the Processing version in the directory path so that new versions don’t overwrite existing ones.

Please add the portable version installer or the .tar.gz versions to the Processing download web page and make it obvious that your current “download” link is a forward to Canonical’s Snap store.

7

Thanks for the feedback @scudly.

If you prefer the portable version, it’s available on the GitHub releases page. We haven’t linked it prominently on the main site because it can be confusing for beginners, but we know it’s useful for more experienced users like you.

Our goal is to keep Processing accessible for everyone, from first-timers to long-time users. That includes making installation as straightforward as possible for newcomers, while still offering flexibility for those who need it.

We’re not opposed to including links to the portable versions on the main download page, but we want to do it in a way that keeps the options clear and legible, especially for people just getting started.

Really appreciate you taking the time to share your thoughts, it helps us make better decisions.

8
Feature Snap Flatpak AppImage
Sandboxing Yes (via AppArmor, not always strict) Yes (mandatory, uses Bubblewrap) Optional (not enforced)
Dependencies Bundles most dependencies, may rely on other snaps Shares runtimes across apps Bundles all dependencies
Installation Requires snapd daemon Requires Flatpak runtime and integration No installation—just download and run
Updates Automatic updates via Snap Store Delta updates via Flatpak repo Manual or via AppImageUpdate
Portability Not portable (requires snapd and system integration) Less portable (depends on runtime) Highly portable—can run from USB
App Store Snap Store (centralized) Flathub (centralized) No official store
Use Case Good for system-wide apps and IoT devices Ideal for sandboxed desktop apps Great for portable, standalone apps
Startup Speed Often slower due to mounting and sandboxing Moderate Fast
Created By Canonical (Ubuntu) Red Hat, Endless, Collabora Simon Peter
1 Like
9

Thanks for that; replaced the snap install by the portable version and it immediately solved my serial port problems.

Linux is not the most user-friendly OS but I can find my way around (I’ve professionally worked with various distros for the last 25 years including software development and server maintenance). Having to dig into snap to enable serial port access is however a bit too much asked now I’m retired :wink: