No more applets with Processing 2.0a7

Summary: Processing dropped the support for exporting Java Applets, therefore you won’t be able to share your sketches on OpenProcessing directly. This is a something that will effect many of us and OpenProcessing.

Plan: Javascript sketch uploads will soon be supported on OpenProcessing (in a week or so). This way you will be able to upload your sketches that are in javascript mode in Processing.


Currently, I am assessing the situation and seeing the changes necessary to support sharing of your Processing 2.0 sketches. Basic roadmap is:

  • I will redesign the upload process to support javascript/Processingjs uploads.
    This means that you will only be able to share your sketches that you created in Javascript mode in Processing. You can change the mode of your sketch by clicking on the dropdown at the top right corner that says Java. However, this will come with some limitations:
    • You will not be able to use external Processing/Java libraries like minim, controlP5, etc.
    • A few functions are not available. The list of functions and reference for processingjs sketches are here.
    • On the plus side:
      • Your sketches will now work on iPads, Androids, and almost all platforms that support HTML5.
      • Your sketches will not be dependent on the doomed future of the Java Platform.
      • Viewers of your sketches will not go through weird steps of enabling java, allowing permissions, etc..
  • Old upload process for applets will be provided as legacy: This will help if you are still using Processing versions prior to 2.0a7, or if you have a sketch using Java libraries, dependents that don’ t work with Processingjs.

How will you be effected: You will still be able to work on your sketches on Processing as you did before. However, when you want to share them on OpenProcessing, you will have to make sure your sketch works in Javascript mode, that you can select at the top right corner in Processing. To share a sketch that uses Java libraries or other dependents that require Java mode, the legacy support will be there so you can export your sketch and upload via using an earlier version of Processing.

How it is going to effect the community: Well, this is a tough questions to answer. Many advanced level sketches on OpenProcessing use Java/Processing libraries at the moment. After this change, we will not be able to see these sketches anymore, since they will not be exported as Java Applet in Processing. They will not be web-browser friendly any more, therefore it will not be possible to share these on the web.

Unless it is a hard download link, which takes away the browsibility aspect of sketches.  Would you have viewed any photos on flickr if it require you to download each image on your computer first? No.

However,  my hope is that this change will also encourage the community to make Processing more web-friendly, by putting emphasis on Processingjs. Processingjs would come to a great place if it starts to get supported by libraries like physics, minim, controlP5. Some of these libraries might not work in javascript sandbox environment, however, solutions can be found with Chrome/Firefox extension to support such features, etc. But overall, this is the part I can’t quite figure how it would work out. I guess we have to say, change is good, and we’ll see together how it works out.

I am really interested in hearing your thoughts on this. If you have comments, please provide below.


  • java applets that have already been uploaded will still be archived, correct?

  • There are some Processing libraries being ported to ProcessingJS, like the fine toxiclibs.js by Kyle Phillips. So that should probably work if you can implement it in a good way.

    For the uploading part: do you have an API available? I was talking to some people last night and we came up with an idea for a tool that can upload sketches to OpenProcessing right from the PDE.

  • I suggest you (or the community) look into writing an OP tool that can do applet export by itself. Should not be too hard as you can use the 1.5 export codebase as blueprint.

  • Ha, there you go ..

  • @Florian and @Jan: I think the direction we should take should be to deprecate the Java Applet support fully, so that we can move on, and port Processing as a whole (with its libraries, community) to Javascript world. God knows when Apple will pull the plug on supporting Java in full. Oracle doesn’t seem to be improving Java at all (both technically and politically). (Not trying to open a bigger topic here, but here I said it :) )
    Therefore, I don’t think bringing the same export functionality back to Processing 2.0 as a plugin is a good solution. I am backing Ben and Casey. However, my ideal approach would be to eliminate Java fully from Processing, making Javascript the main language, and porting libraries to Javascript. It is good to hear that toxiclibs has a js version.
    Of course there is the sandbox issue for many things (serial connection, etc.) but I feel like there might be solutions to that (browser plugins allowing access to serial, file system, etc.?)

  • You can consider looking into Java’s Web Start, which allows you to launch Java applications from the browser.

    I’m pretty disappointed though, at how we’re moving away from Java. It seems to me to be the best medium for presenting complex sandboxes quickly and efficiently.

  • So that’s it, one day it really had to come.. Java applets becomes quite obsolete nowadays in web browsers. So of course some custom tool for exporting from Processing PDE wouldn’t be probably so difficult to make. But this “extra” tool is not very welcoming for average use.

    I completely agree with Sinan’s statements above.. it seems that the most pragmatic is to follow Processing’s devs and drop Java support completely. I think this step is quite necessary long term goal as Oracle is a kind of company nobody want to be dependent on.

    I am not really a great JavaScript fan but it seems this language is much more compatible for more users.. and so it is developing as well much more nowadays.

    Interesting question is (?!).. for how long it will be possible to even keep Java applets running online.. this media shows it’s temporarity pretty soon to us.

  • Great move!
    For me this is perfect, java applets, like flash ‘swfs’ are not browser friendly, all thought I didn’t really mind them … but you have to adapt yerself … and I guess that’s the whole reason,

    JavaScript is certainly the best way to distribute our processing sketches online right now, so let’s go for it.

    Maybe one day the browser will let us execute bytecode — untill then I’m into JS mode

  • I don’t think you’ll be able to achieve the smoothness of the Java sketches with JavaScript – even Chrome’s JS implementation is still quite a bit slower (and jerkier due to more frequent and obvious garbage collection pauses) than Java. Instead of using applets which it is true are a dying breed, why not look at packaging up sketches using Java Web Start (

  • For web-based projects deprecating the java-applet may be not the baddest idea.
    But I don´t think stepping away from Java as a whole is a good idea, since it is considerably faster, better to maintain and extend than js.
    Developers should be able to leverage big non-web projects and applications with Java.

  • I agree that it will take sometime for browsers to catch up the speed of actual java. However, my main concern is that, people who need to use Java for performance and more importantly library access purposes (lots of libraries written for Processing, but almost none for Processingjs) will not be able to share their sketches online.

    But, we have to make the move and see. I guess this will be a partial transition for the most of the community, as we will get used to working in processingjs/javascript mode instead of java/applet mode, so that library developers will do so in javascript as well. This way, most projects will be sharable!

    Thank you for your support on this move!

  • Hey, I try to upload a Sketch that uses minim library, but in OpenProceesing doesn’t work. because of that reason you said. but for now, what can I do?

    thank you

    • You can use Processing 1.5 version to export your sketch as java applet and upload. Upload section on OpenProcessing still allows you to upload legacy Java Applet sketches.

  • I understand the move to discontinue applets in Processing 2.0, but I have no doubt someone will write an external applet export tool. Either way I think it would be a good idea to keep applet upload as an option on OpenProcessing. For my own purposes no applets means no custom libraries (including my own Modelbuilder, which I use in pretty much every sketch I make.)

    I’m considering a JS port of the core Modelbuilder functionality, and this latest development only makes that more of a necessity. But I’m not exactly relishing the prospect of maintaining one more code base, and I’d like to have the option of using applets for now.

    I agree that Oracle’s indifference is ominous and that Java’s security fails have done irreparable damage to its reputation. I’ll even agree that there is some logic to the speculation that Java might become the next COBOL in the not-too-distant future. But it’s not dead just yet.

  • I can’t install javascript module in processing 2 so I can’t do that.. :( It always encounters error.. :(

    • Can you give me more specific information about why you can not install it? Do you get any error messages? You can send me the details (a screenshot would be helpful) to “info [at] openprocessing [dot] org”.

  • I won’t waste any bits defending Oracle… However, Java isn’t about to disappear. Quite to the contrary, Java is doing a lot better than it was a few years ago. Why? The obvious answer is Android. However, a deeper point is that a rather large portion of new languages target the JVM. A short list from Wikipedia includes ColdFusion, JRuby, Jython, Groovy, Scala, JGNAT, Clojure, MIDletPascal, and JavaFX Script code.

    Another important point is the enormous range of Java libraries. The Bouncy Castle encryption library is just one of many, many examples.

    For the record, I have done some work with processing.js. It works rather nicely… Except when it doesn’t. Enums aren’t supported. Array.size() doesn’t work. Worse, things that don’t work just fail (no error messages).

  • Is it possible to use minim.js with your sketch on open processing. I know I can use it as an include on an HTML page, and my sketch works fine. But how do I do that on OpenProcessing??

    • Sorry I missed this comment. Minim.js not at the moment, but it will be supported after redesign, which is in the works at the moment.

  • I think Java is a great technology and dropping the support doesn’t make sense since Processing language is build on the Java language. What ever the cross compiled output is, targeted technology is fairly important to keep the performance good. I like to see Javascript cross compiled implementation targeting not canvas but WebGL. That might be the closest thing we can get to Java Applet. To me processing.js is still looking like a hack than real cross compiled output. If we can cross compile all the libraries, and find ways to punch holes on fairly restricted web browser sandbox (which is almost impossible) than we might be on to something. But that will be huge thing to accomplish.

    • As you mentioned, it is quite big task, however a group is currently working on a native javascript library for Processing (which should also support WebGL) at p5js. I am planning to add this option along with processing.js in the redesign of the OpenProcessing. I believe this will provide us more browser-friendly and powerful sketching options.

Leave a Reply