Using Java 9 (jre-9.0.4) in Processing (3.3.7)

Hello everybody,

we are using a .jar library in our processing (3.3.7) sketch, which is based on java9. Is there a way to direkt the processing sketch to java9?

Thanks in advance, for any kind of suggestions!

This is the error:

java.lang.UnsupportedClassVersionError: ________________ has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(
    at Method)
    at java.lang.ClassLoader.loadClass(
    at sun.misc.Launcher$AppClassLoader.loadClass(
    at java.lang.ClassLoader.loadClass(
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(
    at java.lang.Class.getConstructor0(
    at java.lang.Class.getDeclaredConstructor(
    at processing.core.PApplet.runSketch(
    at processing.core.PApplet.main(
This version of Processing only supports libraries and JAR files compiled for Java 1.6 or earlier.
A library used by this sketch was compiled for Java 1.7 or later, 
and needs to be recompiled to be compatible with Java 1.6.


  • edited March 2018
    • Java 9 adds modules to the language, which breaks Java's ecosystem by a lot! :-&
    • In order to use Java 9 compiled ".jar" libraries, you're gonna need for a Processing version fully compatible w/ it. I-)
    • Or recompile those libraries using Java 8. :ar!
    • We can also ask the devs for Java 9 quicker:
  • thanks for your answer! Our question would be, if there is a processing version, fully compatible with java 9 at all - since this is not an option processing gives you before downloading.

  • @mmathias -- re:

    Our question would be, if there is a processing version, fully compatible with java 9 at all

    No, there is not.

  • edited April 2018

    I have been working on the possibility of using jdk9 with JRubyArt and propane, both essentially ruby wrappers around processing. I have concluded there is not much I can do with JRubyArt, which relies on a user installed version of processing, however I have found a workaround by compiling my own version of processing-core (albeit with jdk8) for propane. Most sketches apart from those using javaFX actually run OK with jdk9, however with opengl there are a lot of warnings

    PS: I'm not saying that you could use propane to use your library as currently configured, but if it was compiled with jdk9 instead of jdk8 it probably would, these are experiments I have yet to do (because at present backward compatibility to jdk8 is important).

    Update:- won't compile with jdk9 because is referred to in, and since jdk9 proprietary code is not available.

  • @GoToLoop - Processing is never going to support Java 9. In fact, Java 9 has already been superseded by Java 10, neither of which are LTS. Processing should eventually support Java 11 (LTS) coming out in September.

    @mmathias - what's the library? Can it be recompiled for Java 8? A library requiring Java 9 is somewhat unusual at the moment.

  • edited April 2018
    • @neilcsmith_net, Java 9 is & represents the version which brings out package modularity for the Java's ecosystem.
    • Modularity is the breaking change and the main obstacle for Processing to overcome.
    • The exact version (9, 10, 11 LTS, etc.) Processing will finally be able to pull that out is another matter.
    • BtW, Java 11 LTS is gonna remove JavaFX as a bundled module. Yet another headache for Processing to deal w/.
    • And Java 10 rolls out an alternative way to declare local variables w/ var. Another feature for PDE's pre-processor to be compatible w/.
    • PDE's pre-processor still needs to be compatible w/ Java 8's lambdas & interface default methods.
  • @GoToLoop - yes, just making the point that the Processing devs have already mentioned the intention not to officially support running on Java other than LTS. And note that running on and supporting the features of are not the same thing - see monkstone's comment.

    JavaFX being removed from the core JDK may not actually be a bad thing for its development, and may not prove to be too much of a headache.

    And it's no secret I think the pre-processor is a bad idea! It holds back supporting newer language features for very little gain.

    Still, all this is getting even more OT! ;-)

  • edited April 2018

    And it's no secret I think the pre-processor is a bad idea!

    IMO, PDE's pre-processor is what makes Processing easier for beginners. B-)
    It makes Java easier than Python! ~O)
    However, it shoulda been the decade ago for PDE's pre-processor to be fully Java compliant. [-(

  • The API is what makes Processing great for beginners. The minimal language changes in the pre-processor add very little, cause bugs and lots of extra work for the devs, and keeps Processing syntax behind Java's. The wrapping everything in a class would be better handled by the editor.

    Anyway, that's my opinion ... and going well OT.

  • edited April 2018

    Well, I'm happy PDE's pre-processor "eliminates" this whole "complicated" block: \m/

    import processing.core.*;
    class MyPApplet extends PApplet {
      public static void main(String[] args) {
        runSketch(platformNames, new PApplet());

    That thing is what makes Java worse for beginners than Python! 3:-O
    Remove that outta sight and Java can finally be used for teaching beginners as well! :>

  • Yes, and as I said you can do that entirely within the editor without changing Java's syntax at all (the approach used in Praxis LIVE's editor, hence how it can support all of Java 8 without needing the extra boilerplate you mention). Maybe look at some other Java educational tools too.

  • Maybe look at some other Java educational tools too.

    Like Greenfoot? O:-)

Sign In or Register to comment.