Howdy, Stranger!

We are about to switch to a new forum software. Until then we have removed the registration on this forum.

  • When will Processing IDE shift to Java 8

    @Lord_of_the_Galaxy :)) by a long and tortuous detour into Kotlin. You do realise your "sooner or later Java 10" happened two months ago?! That introduced var which might be quite nice in Processing.

  • When will Processing IDE shift to Java 8

    @neilcsmith_net, I dunno Kotlin yet. But I'm suspicious that any JVM language can't really fully transparently cross the difference between primitive & wrapper objects. It's set in stone inside JVM. :(

    I believe that C#'s .NET Framework's VM was developed w/ that autoboxing conversion in mind from the get-go. B-)

    When it's spotted that a wrapper value object can be safely used as a primitive instead, the .NET's VM transparently removes its wrapper completely behind-the-scene from that moment on; and it is then accessed w/o any indirects! \m/

  • When will Processing IDE shift to Java 8

    Autoboxing is runtime, which is slow.

    I said autoboxing because I meant autoboxing! :-P Autoboxing happens at compile time. Object creation (or unwrapping) happens when needed at runtime, same as in Kotlin - Kotlin just takes it further, and in the process hides something useful! The problem is that when you remove primitives from the type system you make it harder to enforce use of primitives (eg. this issue, or the need for IntArray, etc.)

  • When will Processing IDE shift to Java 8

    Even if there are no primitive types in Kotlin, the compiler uses them wherever it can.

    I dunno all the programming languages there exist which automatically primitivize number wrapper objects when the compiler can spot they won't ever be used as an object later on. :-/

    I only know these 2 for sure: C# & Dart. Maybe JS as well? :\">
    How is JS internally implemented is still a big mystery for moi... ~:>

    Java is old school like C, C++, D, etc. We can rest assured 100% that a variable declared w/ a primitive type will always hold a primitive value; not relying on compiler's AI optimizations uncertainties. ~O)

    Although there are exciting future plans for Java to close that primitive/wrapper object's gap very soon, w/o breaking anything! \m/

  • When will Processing IDE shift to Java 8

    @cansik - yes, this is really probably not the right place for the conversation! :-\ I have looked at Kotlin quite a bit, actually, just not written anything in it (which would be the obvious next step, I know).

    I know the Kotlin compiler uses primitives where ever he can, which is exactly what I don't like about it - it's pretending to be something it isn't - like autoboxing on steroids. You still need things like IntArray for performance, which kind of makes a mockery of it! Same as extension methods - they're pretending to be something they're not - eg. they're resolved statically.

    Talking about performance when both are running on the JVM is not nonsense - languages that run on the JVM do not perform equally. Kotlin should (could) be similar, but you need to know what is happening underneath. eg. if you're not careful, "primitives" and lambdas can cause a lot of object churn in Kotlin.

    Kotlin and Java are both open-source backed by commercial companies (only free Oracle JDK from now on will be OpenJDK!), so really no difference there. And having a language backed by a company that makes money from the tooling is not a pro, because there is little impetus for them to make things work well with other tools! ;-)

    Interested in what you mean by working on realtime stuff with Kotlin? Realtime use of Kotlin compiler? Any links?

  • When will Processing IDE shift to Java 8

    @neilcsmith_net I recommend you to really look into kotlin. You mention things here which are just not true. Even if there are no primitive types in kotlin, the compiler uses them where ever he can. For example

    val myInt = 32.3132.toInt()

    is compiled to (decompiled from kotlin generated bytecode):

    int myInt = (int)32.3132D;

    So there is no overhead because of that. I use kotlin for realtime applications (as your Praxis), and it is as great as java. Talking about performance, when both are running on JVM is just nonsense.

    The great advantage of kotlin is, that you get a lot for free as developer (implementation wise: Singleton, Immutable classes and so on). And you are more guided to write clean code, because it's a design principle of the language.

    Writing a singleton class in kotlin is just by using the object keyword, instead of the class keyword. I know that it is not as easy in java.

    Kotlin is open source, but backed by Jetbrains. Why is that a con? So you like Oracle with it's closed source strategy better? Backed by a big player helps a language to quickly spread (is now also adopted as official Android language by Google).

    I would love to hear your arguments against extensions methods, instead of a "meh". But this thread is not about kotlin vs java .

  • When will Processing IDE shift to Java 8

    @cansik at no point did I say Kotlin has no value. Just that the things I value most in it are coming to Java in the next ~12 months. All languages have pros and cons, and I would probably choose a completely different language if I was choosing to replace the amount of work I do in Java. I've seen this hype before ;-) For me personally, Kotlin's greatest value is pushing Java development to happen faster.

    In particular, as well as disliking the syntax, I actually think it being backed by Jetbrains (a developer tool company) is more of a con than a pro. The no-primitive-types situation is not always a good thing - it hides some performance realities, particularly relevant in media stuff. Singletons are just as easy in to implement that way in Java, it's just people over-complicating things (in Java, who'd-a thought it). Extension methods - meh! So, what you value is not what I value. That's why there is more than one programming language! :-)

    Oh, and Graal already allows both Java and Kotlin (and other JVM languages) to be natively AOT compiled! ;-)

  • When will Processing IDE shift to Java 8

    @kfrajer I don't see a reason why processing should add a kotlin support. It is definitely great for coding, but with kotlin support, also the documentation has to be updated and so on. I see kotlin more for people who are using Processing as framework, not as IDE. But if someone has some free time, I would definitely love to teach my students kotlin in processing, instead of java ;)

    Btw. here are some kotlin & processing projects I was working on:

    @neilcsmith_net Telling that Kotlin has no value, because the features are coming to java in the future, is not understandable. Java is way behind C#, which is the reason why people started thinking about writing a new syntax for the JVM. Kotlin is backed by jetbrains, so the developer tools for kotlin are great, and the language is targeted for production efficiency (difference to scala). They built a lot of good features into koltin, which maybe are adapted to Java.

    But also here are some reasons, why I think, kotlin really is worth it:

    As you mentioned, the type system in kotlin is great. You do not have the separation between primitive and reference types, all types are equal. This leads to less confusion for developers and more pre-checked code for the compiler. The same applies for the null-safety, which helps to write more clean code, even for beginners.

    How many times have you seen a singleton pattern implemented the wrong way (double check lock f.e.)? Kotlin uses a simple way to implement singletons, which is thread safe (static initialization block). But you as developer have not to care about it.

    I talked about extension methods before, and will here again. They are great if you know how and when you should use them. As I showed in the example before, it is great to give a library a stronger contract. You could also use them to make opencv functions more friendly to use.

    These are just a few features I love about kotlin, and these features are already there! I can just start and write my code, and because you can compile kotlin to java 6 or 8, it will run on a lot of clients!

    Btw. talking about features that are announced: Kotlin Native is just around the corner. The language with it's safety features could be a real competitor to C++.

  • When will Processing IDE shift to Java 8

    The Processing pre-processor does two things, structural changes and syntax changes. It is the syntax changes (float/double and color, etc) that are a PITA, because they make it difficult to keep up-to-date with Java changes. In PraxisLIVE I have some similar structural support, automatically wrapping in a class, making things accessible, etc. However, I don't support the syntax stuff and therefore supporting Java 8 is easy - and lambdas / method references are great - can really lead to some easier to understand code!

    Java 10/11 introduce type inference eg. var. And raw / multi-line Strings are also coming!

    Java 12/13 next year are intended to support record (data) types, value types, expressions in switch statements, etc. I have a photo of a slide from recent JAlba unconference (below) which had a session on this. So, really the only thing Kotlin has that I'd like and isn't coming to Java in the next year is better null support. Spoke to a couple of other Java devs recently who'd started with Kotlin and were now finding it frustrating, although I probably know more who love it! :-)

    My primary project, PraxisLIVE, is based on Apache NetBeans (which I'm also involved with), and I'm waiting for the full release of NetBeans v9.0 with Java 9+ support before completing migration there. I only intend to support Java LTS releases anyway (eg. 11 and 14), which I believe is the same as Processing's plan. Other libraries such as GStreamer bindings which Processing Video also uses are working / tested on Java 9+, but the code is not even being migrated beyond Java 1.6 syntax just yet.


  • When will Processing IDE shift to Java 8

    The Processing pre-processor is a PITA!

    What do you mean @neilcsmith_net?

    Maybe I should spend more time with Kotlin, because the more I look so far the less I like

    You are saying that why to invest in Kotlin when Java is improving and including all these features? Am I reading you correctly? That is a good question. Would Kotlin take over Java in the future? Can anybody answer the question? Would code readability and "bolier-plate code reduction" (beside other features) enough incentives for people to move to Kotlin? I feel those are not enough incentives for people to try as there is a learning curve when it comes to writing Kotlin (code syntax) and to use it properly.

    Tell us about changes looming with Java11 if you can (also changes in 9 and 10?). Are you putting any effort to migrating your code bases to these newer versions? Is there a need to do it?


  • When will Processing IDE shift to Java 8

    Maybe I should spend more time with Kotlin, because the more I look so far the less I like. Some of the best aspects are coming to Java too - talk about Processing supporting Java 8, Java 11 will be out in a few months! ;-)

    The Processing pre-processor is a PITA!

  • When will Processing IDE shift to Java 8

    @cansik Do you see the potential of having Kotlin mode in Processing? In your projects, do you find yourself mixing Java and Kotlin or do you just focus in writing K code?


  • Can we develop p5js in Kotlin?

    Can we develop p5js in Kotlin simply by replacing keywords in these two languages? And if I can not, what I should do to make p5js support Kotlin?

  • Chaining Shaders and Feedback

    @toneburst Sorry for my late reply! What you've done looks amazing :) It's nice to see people play with my library.

    Instead of all that pixel loading stuff and copying the camera image onto your camFrame I would recommend to do it like that (processing standard):

    camFrame.image(cam, 0, 0);

    It runs smoothly with 30 fps, I will check it with a 60 fps camera later, but I don't have one here atm.

    Just a hint when working with Capture: Sometimes the camera takes a lot of time to init & load and then processing has a timeout. Maybe it is makes more sense to load the the camera in the draw method. Here is an example:

    It is written in Kotlin, but it should be easy understandable for Java developers :)

    Is there something else I can help you with?

  • When will Processing IDE shift to Java 8

    Kotlin & Processing

    I am currently using Kotlin as main language for my processing projects. But I stopped working with the Processing IDE and work with IntelliJ and gradle.

    Kotlin is great for developing with processing and also safer, for example the beginDraw and endDraw states can be turned into a nice extension method:

    fun PGraphics.draw(block: (g: PGraphics) -> Unit) {

    Then you just have to call it like that:

    val myGraphics = createGraphics(500, 500, P2D)
    myGraphics.draw {
        it.image(myImage, 0f, 0f)
        // draw ellipse
        it.stroke(0f, 0f, 255f)
        it.fill(0f, 0f, 255f)
        it.ellipse(100f, 100f, 50f, 50f)

    Also the val and var type inference is great and makes it much more readable and safer to develop in teams.

    I have implemented some other extension methods to work with kotlin, check them out here (maybe there are also some for OpenCV, because I use it in this project):


    Java 8 and Processing

    The Processing IDE is nice for beginners or to sketch something, but once I started a big project with it and it grew up to over 30 files (LED Forest 1). Then I decided to start new projects only in a real IDE (LED Forest 2) because it is real pain to handle 30 different files in the Processing IDE.

    So I think there is no real need for Java8 Syntax support in the processing IDE, if you really want to develop a real application, use a real IDE.

    Maybe it would be good to share more Project Templates for common IDE's. It's really not that easy to setup a processing project. I have now my templates, but it was a real pain to find out all the native binding paths and such things.

  • When will Processing IDE shift to Java 8

    @nabr, there are only 3 Processing libraries currently: L-)

    1. Processing Java:
    2. Processing JS (Pjs):
    3. p5.js:

    2nd & 3rd are libraries written in JS language. While the 1st is written in Java. ~O)
    And all the other Processing mode flavors depend on Processing Java's library.

    Given Kotlin is a JVM language, it's possible to turn it into another Processing flavor, like Python & R modes and many others. :-bd

    However for Rust, some1 would need to re-write Processing library for it, as already happened to Pjs & p5.js flavors. #:-S

    For C++, although technically not Processing, but similar to it, there's

    And if we look at it, language C/C++ flavor is more or less represented as Arduino IDE. :P

  • When will Processing IDE shift to Java 8

    @kfrajer when you know one language very well, it is less a troubel to learn a new language. p5 .js -java script / no i talking more about IDE Java mode. It's more a idea i got 5 minutes ago, nothing serious jet.

    My point is: You always waiting on some guys to update the language reference, do i get a """multiline string support, you just don't know"""

    And for a big company with a SDK, what matters, during a progress, if it fit's with their company plans. Gain value, - profit.

    Back 15? years ago, when processing was founded, i think, their were not much to choose from to build upon an Programming Environment with cross platform support and feathers you all know.

    But know things has changed, new languages are in the wild, and what realy new about them is, - they comunity based. You can log in a forum, and start a discussion. do i get """multiline string support, log in in a forum and start a discussion, when your arguments are right why not"""

    So when i read this

    you always waiting: First for a new language reference and then for the dependencies to get updated.

    I heard form kotlin becourse they have a good OpengGL (JavaGL) support, so no more Ant or Jogl (Jogl also comunity based project) and far less Java, more Java, that develops, based on "likes" in a forum.

    Also Processing is a comunity driven project, whit a more flexibel community driven language, - they could influence each other and grow.