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

6 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.