Modularity of Core in Processing 4 #JPMS

Moving a discussion here as requested - https://github.com/processing/processing4/issues/63

I’m currently working on a fork (for PraxisLIVE / Codelerity) splitting up Processing Core, modularizing and pushing to Maven Central for our and other use. Has any thought been given to splitting up Processing Core and using the Java Platform Module System - eg. Core (with abstract GL), AWT, JavaFX, JOGL(?), LWJGL, etc.? Given increasing dependencies, modularity and possibly JLink might be good for handling sketch export in future?

3 Likes

I have no thoughts on this, but I would be happy to read about yours :slight_smile: What are the current problems and what benefits / drawbacks does splitting the core have?

For us, splitting Core into different modules / JARs means it’s possible to just ship what’s required. However, while doing this I thought that this would also be really good inside Processing itself. JLink, which is built into the JDK, allows to build a self-contained modular application with only the bits of the JDK and third-party libraries that you actually need. The additional packaging stuff to make installers, etc. is coming with JPackage.

If Processing Core was properly modularized, it could make use of this infrastructure when exporting sketches such that you get a self-contained application with only the bits of the JDK, libraries and Processing you need to run it. eg. don’t ship JavaFX, LWJGL and/or JOGL unless the sketch needs them.

Splitting core would have some minor backwards incompatibilities, so good to do for v4. The rest could be done incrementally on top of it.