When will Processing IDE shift to Java 8

Lord_of_the_Galaxy

Why doesn't Processing IDE shift to Java 8? Is it even possible? If so, when will they do it? Does anyone have some information?

UPDATE: Is there any way to use Java 8 libraries in the Processing IDE?

GoToLoop

https://GitHub.com/processing/processing/issues/4484

Lord_of_the_Galaxy

That's... sad :((
I really hope they do make the transition, it can come of a lot of use.
I just don't see why they can't just change the ANTLR version. I suppose that the number of people working on Processing is just way too less to get things done fast.

Lord_of_the_Galaxy

Is there any method of using a Java 8 library in the Processing IDE?

Lord_of_the_Galaxy

Solved part 2 - https://forum.processing.org/two/discussion/15897/how-to-import-the-javafx-library

GoToLoop

I suppose that the number of people working on Processing is just way too less to get things done fast.

• While indeed the staff is underpowered, I refuse to accept such excuse.
• IMO the problem is caused by arbitrary choice of priorities rather than # of folks working on it.
• The transition from Processing 2 to 3 was a big endeavor. And needed lotsa devs for it.
• However, the # of new features brought to 3 is merely a fraction of what happened from Processing 1 to 2.
• Actually I daresay it brought more problems than actual useful features.
• Like the settings() "feature" and the loss of Applet inheritance.
• For the PDE, we got partial code completion, error warnings & debug mode.
• But I simply turn them all off. Those irritating warnings and code completion get in my way.
• Instead, I woulda preferred they had simply made the PDE & its pre-processor fully compliant w/ Java 8, especially its lambda arrow syntax!
• In short, it's a matter of priorities. If they were able to pull off the removal of Java's Applet dependency, by replacing its functionality w/ class PSurface, they woulda easily been able to make the PDE an actual Java 8+ IDE! [-(

GoToLoop

Is there any method of using a Java 8 library in the Processing IDE?

Well, we can't even use Java 8 syntax inside PDE's ".java" prefixed tabs, even though it is actually running under Java 8!

Only way I see it possible is by compiling Java 8 syntax w/another IDE or directly in a terminal! =;

Lord_of_the_Galaxy

Well, we can't even use Java 8 syntax inside PDE's ".java" prefixed tabs, even though it is actually running under Java 8!

Only way I see it possible is by compiling Java 8 syntax w/another IDE or directly in a terminal!

Are you sure? It seems to be working.

GoToLoop

Not in my PDE version 3.3. Maybe they've fixed it for latest version. Enjoy it then! <:-P

Lord_of_the_Galaxy

Actually, I'm using 3.2.3 :-/
And I meant using Java 8 libraries, not Java 8 syntax.

GoToLoop

And I meant using Java 8 libraries, not Java 8 syntax.

Then why did you quote me speaking about syntax, stating it's working, if you actually meant library: :-@

Well, we can't even use Java 8 syntax inside PDE's ".java" prefixed tabs, ...

Lord_of_the_Galaxy

@GoToLoop sorry for misunderstanding, I thought you meant libraries included

Well, we can't even use Java 8 syntax inside PDE's ".java" prefixed tabs, ...

since the discussion was previously libraries, and you used the word even. :(|)

GoToLoop

• Like I've said, PDE is running under Java 8 for a long time already.
• Obviously it can accept libraries compiled under Java 8.
• Your title is "When will Processing IDE shift to Java 8".
• In my mind, it was about using Java 8 syntax in the PDE, b/c it's already running under Java 8.

Lord_of_the_Galaxy

@GoToLoop I see.

Lord_of_the_Galaxy

Related - https://forum.processing.org/two/discussion/22269/file-selection-save-dialog-with-filter

nabr

Oracle bought OpenOffice and half of the good guys switch to Libre Office.

I would drop Java of any of my source. And (when) use a similar language, that i can influence.

Javascript make such a great process!

Java 7 or 8 who cares a big scary company look over your shoulder as tells you how to code.

https://kotlinlang.org/community/

kfrajer

@nabr

Would kotlin be similar to p5.js? I was checking the online editor and it gives you the option to run in JVM, js and js(Canvas). What is the concept behind it?

Are you experienced user of kotlin? What are your comments about that language (?)

Kf

GoToLoop

Any language which runs under JVM can be turned into another Processing flavor mode. ~O)

GoToLoop

https://en.Wikipedia.org/wiki/List_of_JVM_languages

jeremydouglass

Two of the entries on the "high-profile languages" list of that wikipedia page -- Jython and JRuby -- are what enable the Processing.py and JRubyArt modes. Renjin is being used for the under-development Processing.R. There is also a fair amount on the forum (mostly examples from @GoToLoop) about using Nashorn to write JavaScript for Processing JVM. https://forum.processing.org/two/search?Search=Nashorn

nabr

@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 https://github.com/processing/processing/issues/4484

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.

nabr

@cansik Rust,C++,Kotlin. Sounds like fun.

GoToLoop

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

1. Processing Java: https://Processing.org/reference/
2. Processing JS (Pjs): http://ProcessingJS.org/reference/
3. p5.js: https://p5js.org/reference/

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 http://OpenFrameworks.cc

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

cansik

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) {
    this.beginDraw()
    block(this)
    this.endDraw()
}

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.strokeWeight(1f)
    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):

bildspur/dysp/Extensions.kt#L31-L46

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.

GoToLoop

So I think there is no real need for Java8 Syntax support in the processing IDE, ...

There was no real need to have an underpowered debug mode in the PDE (Processing's IDE).
Most folks simply rely on println() after all. :ar!

IMO, it is very sad & lackluster that even today, PDE doesn't fully complies to Java 7.
And Java 8 w/ its lambda syntax was launched in 2014. 3 years already! X_X

It's a serious lack of vision neglecting fully Java compliance for the PDE and its pre-processor! 3:-O
Folks shouldn't need to have to use another IDE merely to have Java 8 candies. ~:>

nabr

@GotoLoop: saw processing.js in my visual studio, via NuGet Package Manager. Thank you for the info! I got a C/C++ background, Java 7 or what ever. I just want to crush my car(Object) with 180 miles per hour against a wall and i can't, i just can't.

@cansik: Great! This is very, very usefull. Thank you for the info, i will switch to "real IDE" :)

cansik

@GoToLoop Yeah you are right, switching to another IDE should not be the solution. But I do really understand them, rewriting the whole syntax checker / precompiler is just a really big thing which takes a lot of time.

But that's also my question, why are they reinventing the wheel? Wouldn't it be better to use for example the Atom text editor and add plugins for compile and debug support? So it would be possible to focus on interesting problems and not the syntax highlighting / checking.

I think the problem is, that they have some special treatments of certain types. For example numbers are always directly casted, not like in java.

@nabr Yeah, if you need help to setup your first project, just write me a message.

GoToLoop

Processing as a language, rather than a library, relies on PDE's pre-processor in order to hide away some difficult aspects of the Java language.

Some examples: :ar!

• Suffix all literals w/ a . or an e w/ an f it it doesn't have 1 already.
• Replace all usages of color when used as a datatype w/ int.
• Make all methods & fields public if 1 isn't specified already.
• Concatenate all ".pde" tab files as 1 ".java" wrapped up as 1 PApplet subclass.

Unfortunately there were not enough effort to make PDE's pre-processor fully Java compliant.
I know Processing since version 1.5.1 and the situation is still much the same! [-(

For Processing 3, they've prioritized an incomplete debug mode and an irritating auto-complete, which I turn them all off. :-q

IMO, folks would rather like Java 8's lambdas over those new features mentioned above. =P~

nabr

@GoToLoop where exactly is the problem to add Java8. I recompiled Processing 1 week ago becourse i want to explore lastest Jogl builds and it works great. shouldn't be somewhere linker switch ?

https://github.com/processing/processing/blob/master/build/build.xml

nabr

@cansik thank you, i already setup everything within minutes. not a big deal. java is for kids.

Lord_of_the_Galaxy

That's a lot of information, so thanks everyone for their inputs!
@nabr I'm afraid I'm not sure exactly what you meant, but please note that most programming languages aren't "for kids". Almost all famous programming languages have so much more to them than tutorial websites detail. Even experts do not know some of the finer details, as I'm sure @GoToLoop will agree.

nabr

@Lord_of_the_Galaxy im just fooling around

Lord_of_the_Galaxy

I see. I guess when it comes to the basics, Java is for "kids".

kfrajer

@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?

Kf

neilcsmith_net

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!

kfrajer

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?

Kf

neilcsmith_net

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.

cansik

@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:

• led-forest3
• dynamic-shape-projection
• floje
• image-perspective-transform
• sensitized
• visual-push-x

@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++.

neilcsmith_net

@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! ;-)

cansik

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

neilcsmith_net

@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?

GoToLoop

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/

GoToLoop

Processing as a "programming language", rather than an actual library, caters more for the artistic folks. :D

And Processing's already got the 3 most important languages for them covered, and even beyond: $-)

1. Java as Java & Android Modes: Still the world's most used programming language. C-style syntax. ~O)
2. JavaScript as both Pjs & p5.js flavors: Literally the Java's syntax deployed to the web! Where most artists wanna show up their works! :bz
3. Python as both Python Mode & p5py flavors: Earned its place in academics introductory programming courses, due to its clean (no curly brackets) & easier syntax. O:-)

Of course there are also R as R Mode, Clojure as Quill and Ruby as Ruby-Processing. Maybe more. <:-P
And similar to Processing we've even got C/C++ as Arduino & openFrameworks. \m/

GoToLoop

It's pretending to be something it isn't - like autoboxing on steroids.

Autoboxing is runtime, which is slow. 3:-O

While wrapper object's conversion to its corresponding primitive value happens on compile time. \m/

neilcsmith_net

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

GoToLoop

@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/

neilcsmith_net

@GoToLoop - I know very little about C#, and happy to keep it that way, but this suggests it's very similar. The Java VM will also remove wrappers behind the scenes if it can.

This is getting a long way from the original point! I would love to see Java 8 support in PDE, so that the API gets changed to better accommodate things like lambdas. Or more specifically, method references, which I think are more beginner friendly, as well as useful for the rest of us.

Lord_of_the_Galaxy

I wonder how we reached a discussion about autoboxing from the original question of when Processing plans to move to Java 8, though of course now there's Java 9 and sooner or later Java 10 too....

neilcsmith_net

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