OpenJDK support

[valerio-bozzolan]

(First of all, thanks to this awesome community!)

Trust me, I know that OpenJDK has strange behaviors, but think about avoiding Oracle's JRE for future versions of Processing.

Installing third-party software (or worse non-free as in freedom software) it's something normal for Microsoft Windows and OS X users, but this is a nasty thing for GNU/Linux distributions built over complex dependencies systems, with a wide web of already trusted and packaged software.

Mark this bug as enhancement if you want, but please don't close it. Processing, and Processing users, really deserves to be not forced to use Oracle's software.

[gohai]

I'd also be interested in OpenJDK support on Linux. I'd be volunteering to help triage any Linux bugs that might be caused by using OpenJDK - but as far as I understand, the difference between Oracle's Java and OpenJDK isn't that substantial (anymore).

[monkstone]

Just a comment really but JRubyArt (a port of processing-3.0.2) to ruby works absolutely fine with openjdk (including javafx since 1.8.0_77). There may still be advantages to Oracle java however, the javafx bug got fixed ahead of openjdk for example.

[neilcsmith-net]

+1 to this. Differences between OpenJDK and Oracle Java are minimal, and Oracle's Java build is based on the OpenJDK source - they develop in the OpenJDK tree. OpenJDK is also the Java reference build, so theoretically if there's a difference in behaviour it's a bug in Oracle's version 😄

I'd love to see Processing fully open (as distributed). There are also certified OpenJDK builds for Windows and OSX by Azul (although not with OpenJFX). http://www.azul.com/downloads/zulu/

[guoyunhe]

+1

Another reason is that how Linux package software. If the software wants to included in Debian/Ubuntu/Fedora/openSUSE/Arch/Gentoo Linux, it has to provide a source tarball that can be compiled independently, without downloading non-free binaries from a commercial company, like Orcale.

[monkstone]

Actually Archlinux via community repository already provides https://www.archlinux.org/packages/community/i686/processing/ with Hotspot VM included (ie as supplied by processing.org). Debian on the other hand are very sniffy as a consequence packages such ruby, jruby and even java can be hopelessly out of date.

[gohai]

There's a change already in git master (not yet in a released version, but it should be in the next one), that allows Processing to work with an unmodified JRE out of the box. This doesn't do anything for OpenJDK support per se, but now it is at least possible for distributors to have Processing work together with a standalone Java package without jumping through hoops. (see 71cca0d)

[neilcsmith-net]

@monkstone pity the licensing information in that Arch package is incorrect then! 😄 In fact, I wasn't aware that Arch allowed commercially licensed software in community packages, but maybe I'm wrong there? Oh, and Debian OpenJDK should always be in sync with latest releases, because they're treated as security updates.

@guoyunhe I'd like to see this from a let's make Processing truly open-source point of view, even if still a completely self-contained download. Packaging like standard Ubuntu / Debian packages if it forces dependency on other versions of JOGL, JNA, etc. is likely to go badly.

[gohai]

@neilcsmith-net Agree with your last point. Believe that, in the age of npn and pip, it's pretty clear to everyone that all too strict policies when it comes to packaging and de-duplication aren't really working for users and developers anyhow.

[neilcsmith-net]

@gohai yes, Snappy might be a more interesting packaging mechanism for Processing? http://snapcraft.io/

[gohai]

@neilcsmith-net I meant that not against packaging Processing as distribution packages, but rather against the notion that it couldn't bundle any components it requires. Because supporting this would just be insane. And it seems distributions too are warming up to the idea of the self-contained application that can come with its (tested & proven) libraries: see e.g. Flatpack.

Thinking some simple package hierarchy, that doesn't impact actual development in a negative way could make sense: e.g. a package processing-java-core (just the core library plus JOGL, depending on some installed Java 8), and a package processing (basically the rest minus the bundled JRE, depending on the former).

[neilcsmith-net]

@gohai see eg. Flatpak, Snappy! 😄 I think we're pretty much saying the same thing, and it wouldn't be Linux if there weren't at least two options to have a needless fight over. In fact, they're just the new kids on the block - I remember using some Autopackage distributed stuff over 10 years ago.

Your simple package hierarchy makes a lot of sense.

Somewhat tangential to this issue, I guess, but a good reason for doing it.

[xyproto]

The processing package on Arch Linux uses OpenJDK, and it works pretty well.

There is one issue when downloading some extensions with the Contribution Manager (could be related to how HTTP redirects are handled), otherwise it seems to work fine.

[neilcsmith-net]

Is the contribution manager issue different from #5554 ?

Given there will be no free Oracle Java 8 from the end of next month, and the right to distribute Oracle's JDK from then on is probably uncertain, this OpenJDK move could do with happening quite quickly! AdoptOpenJDK 8 would be the obvious replacement at the moment.

No differences between free Oracle Java and OpenJDK going forward either! 😄 Well, except in duration of free support, which will only be 6 months from Oracle.

[xyproto]

Yes, the issue is very similar to #5554. I think it's the same problem.

[mas-4]

I've been trying to install Processing for the past few days now (I keep finding Pillow for Python [my preferred language] to produce rather ugly effects [no real antialiasing]) but every time I install it and try to launch it I get the error

[Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=gasp                                                                               
-Djava.ext.dirs=/usr/share/processing/java/lib/ext is not supported.  Use -classpath instead.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.]`

I'm installing it in Arch (with i3, if the DE matters) via sudo pacman -S processing. Not sure what the heck that error is. But since I get this message when installing it:

---[ NOTE ]---------------------------------------------------------------
Processing does not really support OpenJDK, only Java from Sun and Oracle.
https://github.com/processing/processing/wiki/Supported-Platforms#linux
If you counter any issues with this package, please file bug reports with 
Processing and/or OpenJDK until Processing can officially support OpenJDK.
--------------------------------------------------------------------------

I decided to try it with the JDK8 from the AUR. It failed that way too.

I'd really like to try it. But @xyproto 's comment

The processing package on Arch Linux uses OpenJDK, and it works pretty well.

Seems not to be the case for me.

[monkstone]

@malan88 what I expect is happening for you is that Archlinux by default now installs jdk11, and the processing launch script doesn't play too well with jdk11. You need to install jdk8, and make that the default java/jdk, which on Archlinux you can easily do using archlinux-java (PS: I have seen the same error as you with jdk11).
See https://wiki.archlinux.org/index.php/java. My ruby versions of processing, work just fine (if somewhat noisly) with jdk11, so I suspect vanilla processing might work with an amended launch script /usr/bin/processing.

[xyproto]

I updated the Arch Linux processing package to use OpenJDK 8, since it did not work with OpenJDK 10 or OpenJDK 11 here, but seems to work fine with OpenJDK 8.

[mas-4]

@monkstone Thank you. It worked. I am unsure why trying the JDK8 from the AUR didn't work. I am suspicious that I didn't install the JDK8 (installing the JDK11 instead). I cannot remember. It works anyway, and I appreciate it.

Thank you, @xyproto for updating the Arch package: it makes far more sense to have it require OJDK8.

[benfry]

Closing this old thread since this isn't a discussion forum; there's work in progress here for OpenJDK.