Processing in style with Java 11

Hello there!

I have been working with some folks on a solution to https://github.com/processing/processing/issues/5750 that includes a bunch of fun things (support for generics, lambdas, local type inference, move to more fully open source stack). Even if some of the new language feature support isn’t the most exciting for you, it helps a lot with keeping the internals of the system ready for the future. Some folks have been trying out the new version while Ben et all continue to work on the code review.

While this isn’t an official build or release, wanted to ask if the more adventurous here (like with mainline processing, no warranty / use at your own risk!) would also be willing to give https://github.com/sampottinger/processing a shot. There’s a link to downloads from the github page or you are welcome to build it yourself! If you encounter bugs, please write back here or, if you have a github account, file a ticket on the github issues page. Also, if it’s working for you, please feel free to write back here with your OS version. :smiley:

Here’s a new sample of code that works under the new build that shows off the Java 8 language features (we also support most of the Java 11 API now too!):

/**
 * Demonstration of Java 11 language features within Processing IDE.
 * 
 * Sketch to demonstrate Java 11 language features within the Processing development environment
 * including type inference and lambdas.
 */

import java.util.*;

List<ColoredCircle> circles;

/**
 * Add a new circle to the global circles list.
 *
 * @param x The x coordinate for the new circle.
 * @param y The y coordinate for the new circle.
 * @param colorGen The strategy to use to generate colors.
 */
void addCircle(int x, int y, ColorGen colorGen) {
  circles.add(new ColoredCircle(x, y, colorGen));
}

/**
 * Processing-standard settings call to size sketch.
 */
void settings() {
  circles = new ArrayList<>(); // Type inference
  size(200, 200, FX2D);
  smooth();
}

/**
 * Initalize this sketch along with its colored circles.
 */
void setup() { 
  final color from = color(255, 255, 255);
  final color to = color(0, 102, 153);
  
  // Lambdas
  addCircle(75, 75, (sec) -> { return lerpColor(from, to, abs(sin(sec))); });
  addCircle(75, 125, (sec) -> { return lerpColor(from, to, abs(cos(sec))); });
  addCircle(125, 125, (sec) -> { return lerpColor(from, to, abs(cos(sec / 2))); });
  addCircle(125, 75, (sec) -> { return lerpColor(from, to, abs(sin(sec / 2))); });
}

/**
 * Draw the circles within this sketch.
 */
void draw() {
  background(255);
  
  // New iteration
  circles.forEach((x) -> {x.drawCircle();});
}

Thanks very much,
Sam

7 Likes

hi Sam,
thanks for the work on Processing 4
and thanks for already starting on new features examples
and thanks for exposing yourselves here ( to our beginner questions )

JAVA 9 introduces

modules / of packages / of classes

how can we use that now ( under Processing IDE 4 beta / JAVA 11 )?
interestingly a file in the sketch path with the name

module-info.java

is invisible in the IDE TAB structure, is that a sign?

Thanks!

Where is the ColoredCircle class coming from in that sample?

1 Like

Hey there @kll!

Thank you for your question. I think you are referring to JEP 261. Right now, this new version of processing will put everything into the unnamed module. I don’t think we are currently planning on supporting a pathway to leave the unnamed module through the IDE or processing-java from the CLI (though I would still advise against using module-info.java for regular development).

That said, the new module system is super nifty. If you want to take advantage of it, you’ll probably want to set up a build system (like gradle) and leverage the new core jar in a more regular java project.

If you have some more thoughts on the module system and have some ideas for how it could integrate with Processing, feel free to drop an issue on GitHub and we can open that conversation up. :smiley:

Thanks,
Sam

1 Like

Hey there @jeremydouglass!

The full gist is at: https://gist.github.com/sampottinger/45f63c1360a6622e9cb59bea978d18eb.

Thanks,
Sam

1 Like

The strong encapsulation of the recent jdk (since 9) currently generate a lot of warnings when used with legacy jars, I have been exploring this in my ruby-processing projects and it seems there are two choices to dealing with this:-

  1. Use --add-opens on command line
  2. Use jdeps to generate module-info and inject module-info into legacy jars.

 jdeps --generate-module-info . gluegen-rt.jar

yields module-info.java:-

module gluegen.rt {
    requires java.desktop;

    exports com.jogamp.common;
    exports com.jogamp.common.jvm;
    exports com.jogamp.common.net;
    exports com.jogamp.common.net.asset;
    exports com.jogamp.common.nio;
    exports com.jogamp.common.os;
    exports com.jogamp.common.type;
    exports com.jogamp.common.util;
    exports com.jogamp.common.util.awt;
    exports com.jogamp.common.util.cache;
    exports com.jogamp.common.util.locks;
    exports com.jogamp.gluegen.runtime;
    exports jogamp.common;
    exports jogamp.common.jvm;
    exports jogamp.common.os;
    exports jogamp.common.os.elf;
    exports jogamp.common.util;
    exports jogamp.common.util.locks;

}
1 Like

I’m currently working on a fork of Processing Core that will use JPMS, splits off JavaFX and JOGL support, and supports LWJGL in a separate module. This will be distributed on Maven Central so available for others to use in full Java projects. But maybe a chance for joining some things together there?

1 Like

Hey there @monkstone! Yeah the reflexive access situation is a bummer. I’m not super excited about injecting that ourselves but I do worry about the libs migrating in a timely fashion. Suppressing also feels bad though. Between the two options, what do you think?

One more thing re the modules… I think it would be quite alright to introduce support within the Processing code base itself. Just not sure how users would create their own modules within the context of the Processing build system (as opposed to using the core jar).

1 Like

Hey there @neilcsmith! That’s fantastic. :slight_smile: I think it’s probably worth taking up with Ben.

  • Re the modules, I am really excited that you did that. I think it is probably worth checking in with Ben on the architectural changes but I’m (in general) in favor.
  • Re libraries, I am happy to hear that you brought in LWJGL! :partying_face: That said, last time I spoke with Ben I think he expressed opinions re introduction of new libs (I know you also mentioned monkeybrains) and I know there’s a history between Processing and LWJGL so we probably need to consult him.
  • Re deployment, I would love to have this in Maven but I know Ben expressed reticence previously (though we have CI and the option for CD now via my fork so maybe the calculus is changing :smirk:).

I would love to look at having our (forces!) forks join together. That said, I don’t think it’s best to go right into my master. I’ve been trying to stay close to resolving issues that Ben has already explicitly “approved” work on in the past (ANTLR4, new Java grammar … I already got in a little trouble for straying from that :sweat_smile: ) within that branch so that there’s a clean first set of merges. My thought is that it may make sense to join your work to my master after I’ve joined back into mainline as this is already a pretty big rewrite of some stuff so it might make sense to stage this a bit. For example, I was hoping to re-introduce CD after my current PRs get merged which might shift the opinion on Maven and I want to drop JEdit after my current changes get through. However, I’ve been holding off on all that until my current master gets hardened via community testing and merged. How do you feel about that approach? Is that too conservative in your opinion?

That in mind, I don’t see an issue for LWJGL after the decision to drop it. Do you mind opening an issue re LWGJL on mainline processing and maybe an issue for modules either on mine or mainline? After that, maybe we can open a branch on my fork that tries to merge our two together? That way we can start staging this up?

If that’s gonna land 1 day, it should be restricted to “.java” files, not “.pde” 1s, I guess. :face_with_monocle:

I am very likely to be guided by what headius (Charles Nutter) of JRuby does because about half the warnings I get with JRubyArt (and propane) come from JRuby, and headius is something of a jvm expert. Currently he is favouring the use of -add-opens, using a special JRUBY_OPTS configuration.

I have been doing further experiments with JRubyArt, where I have a means of easily adding command line arguments to java (using a special java_args.txt file). In this case I have managed to suppress illegal access warnings in a simple sketch using --add-opens). See summary here

2 Likes

Thanks @monkstone! I saw some of the activity on github. Let me know if there’s anything I can do to help. :smiley:

Hello hello! A quick favor to the community, if you are on linux and you are testing these changes out… can you drop a note here with the distro and the rendering engine (P2D, FX2D, etc)? Just trying to feel out where we have folks trying this and where there might be gaps.

@sampottinger apologies for late response - teaching then holiday - wanted to re-read and respond properly.

At this point, I don’t intend to care what Ben’s opinion is on this change. My plan is to modularize and split out the various aspects of Processing core.jar so that they can be used independently of each other, JOGL can be swapped out for LWJGL, etc. for use in other Java projects away from PDE, The fork I have is currently minimal differences from upstream (holding off my desire to tidy up!) so it’s easy to track changes. It would be great to work with you on the changes you’re trying to get merged, and I really hope it does get merged! But the politics of pushing for major architectural improvement and better interaction with the wider Java community in Processing is something I’m happy to remain distant from! :wink:

Again, don’t care! The LWJGL renderer was originally written by Andres as well as the JOGL one. I’ve been having some discussion with him over requirements. And I’m mainly looking at what changes are required to make it work stably across platform, which is mostly in Processing core, including ensuring Processing can work with headless AWT, -XstartOnFirstThread, and a mechanism to run tasks (Runnable) on the main thread and animation thread to handle events. Those changes should improve JOGL performance as well. I’m not sure Andres was that confident on those changes being accepted in core though, which would make LWJGL a non-starter. The event queues would also be great for libraries too - a general invokeLater mechanism is sorely missing, and a reason for numerous threading issues.

You guessed it … don’t care! :wink: My plan is to make this available from the org.praxislive namespace on Maven anyway. I may also port the various other fixes I have for memory handling and fixing alpha blending (premultiplication throughout) from PraxisLIVE subclasses.

I’m happy to work with integrating any of the above back upstream, as you say, should the general calculus change!

What’s the plan with dropping JEdit btw? I know in the past there’s been discussion of a HTML 5 based code editor and use of Language Server Protocol.

Feel free to DM / email me too if it’s useful at all.

1 Like

Hey there @neilcsmith! Let me follow up off thread after I get a little more time away from work but I would love to know more about what you are up to. Do you have this posted in a fork online?

What’s the plan with dropping JEdit btw? I know in the past there’s been discussion of a HTML 5 based code editor and use of Language Server Protocol.

I’ve started looking at this. I may not have the time availability to tackle the whole thing but I wanted to see about getting a language server implemented even if I might not have the bandwidth for the editor. For now though, I have implemented the changes required to get JEdit Syntax stable.

A Processing 4 repo has been posted to the Processing GitHub page. From the README:

This is an experimental fork to attempt the move to JDK 11. Because that’s a major, API-breaking change, it would be Processing 4.

I’m working with Sam Pottinger to incorporate his changes to see if that can be the basis for this new release. Getting things moved to OpenJDK 11 will help the longevity of the project.

It’s not clear if we’ll ship an actual Processing 4.0 , since I have less free time than ever, and very little development help. If you’d like to help, contribute bug fixes.

1 Like

Hello,

Please provide build instructions for this version.

Thanks in advance!

:slight_smile:

A Processing 4 repo has been posted to the Processing GitHub page.

Profound excitement. :smiley:

Please provide build instructions for this version.

@glv - I am working on updating my edits to fit in with some stuff from Ben. In the meantime, please see https://github.com/sampottinger/processing for build instructions.

4 Likes