Processing in style with Java 11

Hey there! For those who have been using my branch, there is a new build available. See for more details.


try windows build under windows 10 64b //
have editor problems
using Backspace key messes the code line up ( cursor/delete position )
but existing programs run / possibly FX2D faster?

Strange… thanks for the report. What zoom are you using for the IDE, what font, and what font size? Thanks!

( it uses same preferences as processing 3-5-3 )

FX2D sketches run error free
P3D shows

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.jogamp.common.os.NativeLibrary$3 (file:/C:/Users/ZEN%202/Documents/processing-40c/core/library/gluegen-rt.jar) to method java.lang.ClassLoader.findLibrary(java.lang.String)
WARNING: Please consider reporting this to the maintainers of com.jogamp.common.os.NativeLibrary$3
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

my sysinfo shows

System     : Windows 10  10.0  amd64
JAVA       : C:\Users\ZEN 2\Documents\processing-40c\java version 2.1 rev JAVA 11.0.1
user.home  : C:\Users\ZEN 2
user.dir   : C:\Users\ZEN 2\Documents\processing-40c
sketchPath : C:\Users\ZEN 2\Documents\Processing\KLL_work_ZEN2\SAM_POTTINGER\test1
dataPath   : C:\Users\ZEN 2\Documents\Processing\KLL_work_ZEN2\SAM_POTTINGER\test1\data

used code is the old stress test, not any of the JAVA 11 features tests

float rset=120, r;
int x = 0;
int w = 400;
int h = 200;
int grid=20, many = grid*grid;
boolean stressenable=true;

void settings() {
  // size(w, h); // default use JAVA2D 
  //  size(w, h,FX2D);
  // size(w, h,P2D);
   size(w, h,P3D);

void setup() {
  println("target "+rset+" FPS");
  background(200, 200, 0);
  println("use key [p] for sysinfo, [n] numinfo, \n[s] stresstest ( "+grid+"*"+grid+" = "+many+" ) points, [+][-] grid +-5" );

void draw() {
  surface.setTitle("SYS INFO "+ nf(r, 0, 1)+" FPS" );
  if ( stressenable ) stress();
  r = frameRate;
  if ( r > 30 )      stroke(0, 200, 0); 
  else               stroke(200, 0, 0);
  line(x, height-2, x, height-2-r);            // FPS graph
  if ( x > width ) { 
    x = 0; 
    background(200, 200, 0);

void stress() {
  for ( int i=0; i<grid; i++) {
    for ( int j=0; j<grid; j++) {
      stroke(random(255), random(255), random(255) );
      point(5+i, 5+j);

void sysinfo() {
  println( "__SYS INFO :");
  println( "System     : " + System.getProperty("") + "  " + System.getProperty("os.version") + "  " + System.getProperty("os.arch") );
  println( "JAVA       : " + System.getProperty("java.home")  + " rev: " +javaVersionName);
  //println( System.getProperty("java.class.path") );
  //println( "\n" + isGL() + "\n" );
  println( "user.home  : " + System.getProperty("user.home") );
  println( "user.dir   : " + System.getProperty("user.dir") );
  println( "  : " + System.getProperty("") );
  println( "sketchPath : " + sketchPath() );
  println( "dataPath   : " + dataPath("") );
  println( "dataFile   : " + dataFile("") );
  println( "frameRate  : target "+nf(rset, 0, 1)+" actual "+nf(r, 0, 1));
  println( "canvas     : width "+width+" height "+height+" pix "+(width*height));

void numinfo() {
  println( "__NUM INFO :");
  println( "byte    min: "+Byte.MIN_VALUE+   "\t\t\t max: "+Byte.MAX_VALUE);
  println( "short   min: "+Short.MIN_VALUE+  "\t\t\t max: "+Short.MAX_VALUE);
  println( "int     min: "+Integer.MIN_VALUE+"\t\t max: "  +Integer.MAX_VALUE);
  println( "long    min: "+Long.MIN_VALUE+   "\t max: "    +Long.MAX_VALUE);
  println( "float   min: "+Float.MIN_VALUE+  "\t\t\t max: "+Float.MAX_VALUE);
  println( "double  min: "+Double.MIN_VALUE+ "\t\t\t max: "+Double.MAX_VALUE);

void keyPressed() {
  if ( key == 'p' ) sysinfo();
  if ( key == 'n' ) numinfo();
  if ( key == 's' ) stressenable = ! stressenable;
  if ( key == '+' ) {
    grid +=5;
    many = grid*grid;
    println("stresstest ( "+grid+"*"+grid+" = "+many+" ) points" );
  if ( key == '-' ) {
    grid -=5;
    many = grid*grid;
    println("stresstest ( "+grid+"*"+grid+" = "+many+" ) points" );

1 Like

Hey there!

Apologies for the inconvenience but thank you for your response. Would you be willing to participate on Github to further look into these? No worries if not and, either way, I’ll update the conversation here afterwards.

FX2D sketches run error free
P3D shows

I filed a ticket for this ( but this is an issue with a library used by Processing (JOGL). The error will not hinder the execution of your sketch and can be ignored for now. Ultimately the error needs to be suppressed, we need to move to a newer JOGL (when it comes out), or we move to LWJGL. At present, I think this is something Ben and another contributor are looking into.

using Backspace key messes the code line up ( cursor/delete position )

Thank you for the additional information above. I filed a ticket for this at I can’t seem to reproduce this in Windows using the settings you provided yet but I will continue looking. Do you have any sort of display scaling set up outside of Processing?

Thank you again for your help,



I sincerely appreciate all the work that is going into this.

I would like to work with these builds and provide feedback.

This I can download and use immediately:

Or build the version available here:

Which one should I be working with?
Where do I submit feedback other than this forum?



Hey there!

Sorry that’s confusing.

Short answer: Use and report bugs at

Long answer: Right now the official fork ( is about a month behind my fork ( and the official fork doesn’t include a number of important bug fixes yet. So, I’d recommend using if you are building from source yourself or if you want a prebuilt binary. That said, the bug tracker is at Ideally there would be an official build to test and you wouldn’t have to mess with my fork at all but the reviews are pretty far behind at this point.



Great Work!

I am pleased to see Processing 4 Alpha 1 build available on the Processing website!

With all the different builds out there Processing users should always indicate which version they are using.

I am using Processing 3.5.4 and occasionally testing Processing 4 Alpha 1.

Please advise on how to report bugs.

I came across this:

And pleased to see this is fixed:



1 Like

@kll @sampottinger @neilcsmith I have been experimenting with JOGL-2.4.0-rc on the RaspberryPI4 and Linux. It seems as thought he reflective access issue (with jdk11+) has been fixed in this release (no need for the --add–opens fix).

1 Like

@neilcsmith Reading through the jogamp bugzilla reports it seems that there is still work to be done for full module compatibility. But unless processing and in my case JRuby move toward using modulepath cf classpath access it should not be problem.

1 Like

Well, I’ve already made the point here, on GitHub, to @sampottinger etc. that I think Processing 4 should embrace the module path, particularly given changes to JavaFX as well, such that JPMS / JLink can become (longer term) the way to distribute stand-alone Processing sketches without requiring a mass of unused libraries.

I’m already using the module path, and have split Processing Core into multiple explicit modules. These will be on Maven Central very soon - working on that now. I have abstracted the OpenGL package to allow for JOGL and LWJGL backend to be swapped in or out. From what I can see in that bug report, I’m not sure using JOGL on the module path will be a problem, but I haven’t tried it yet - LWJGL backend working great, including with third-party libraries as long as they’re not accessing JOGL specifics.


@neilcsmith / @sampottinger – any sense of whether that is going to be part of the Processing 4 roadmap?

Great! Thank you for sharing that work – looking forward to it.

Hello friends!

@monkstone - That’s fantastic news! :smiley: A lot has come together recently. Just finished the migration for the serial library and such. I’m hopeful the JOGL folks will land the 2.4.0 soon but it seems like it will work for us.

@jeremydouglass - I don’t know if that will be or not. However, I’ve mostly been spending my time on bug reports as they come up and that might be more of a Ben question.


That’s good to know. The LWJGL backend actually doesn’t seem to offer much performance improvement, although there are a few things that could be improved in it. It might still be a good choice based on more active development, but that remains to be seen - it’s good to see JOGL development picking up.

I wonder what are your thoughts on abstracting the OpenGL support? I’ve removed JOGL support in processing.opengl and abstracted PGraphics2D and PGraphics3D - only two methods need to be abstract. If JOGL and LWJGL backends were in separate packages / JARs this would allow for easy and transparent support of both, and the option to make one or other the default in future.


…look what’s in the pipe from Sam on Processing4:

1 Like

@jeremydouglass @sampottinger Good to see it seems to work well on MacOS and Windows. For my propane and PiCrate releases I knew it would work for 64 bit linux and 32 bit RaspberryPI.

1 Like

Hey friends!

Thank you to those who have been trying out the alpha and reporting issues. I really appreciate everything. With that, I’ve been active on github but I apologize for being a little less so on the forums. I think the broader global covid situation may have slowed things a bit but I have been trying to respond to issues filed at as they have come.

As PR review has (understandably) fallen behind, I resurfaced my fork of processing4. I have all of the outstanding bug fixes merged together at You can try the latest version of that fork at Unfortunately, the official processing4 master and alpha build are almost 4 months behind now so, if you are free to help test things out, the fork may be best until things catch up.

Thanks so much and hope everyone in the community is well,


Thank you @sampottinger!

For the record, I tried Python mode on Linux and it worked :slight_smile:


I’ll try to test it further! :smiley:

1 Like

Hey @sampottinger, just got your latest release to run on Manjaro Arm (64 bit on RaspberryPI4 4gig RAM).

What I did to get it to work:-

  1. I downloaded the aarch4 linux zip, and unzipped in my home directory.

  2. Found out the included java is not compatible, so I deleted it and replaced it, with a link to the correct java (that I was already using for my PiCrate application).
    ln -sfn /opt/jdk-openjdk /home/tux/linux/work/java

  3. I ran program from console in /home/tux/linux/work ./processing and I was in business. The doesn’t work properly (should be easy to fix).
    For the moment I think Manjaro Arm linux is what to use but with the advent of the 8gig RaspberryPI4, the RaspberryPI OS 64 is now under active development Raspberry Pi 8 giga

More experiments to follow…

Installed toxiclibs library and ran this sketch:-

For my PiCrate application I modified to remove Gottfreid Haiders RaspberryPI fixes (I do not recommend using the Legacy Driver, and we do not seem to need his custom shaders for the fake KMS driver). Makes for simpler code and probably a better look.