Package Details: processing 4.3-4

Git Clone URL: https://aur.archlinux.org/processing.git (read-only, click to copy)
Package Base: processing
Description: Programming environment for creating images, animations and interactions
Upstream URL: https://www.processing.org/
Licenses: GPL, LGPL
Submitter: arojas
Maintainer: lesto (letorbi)
Last Packager: letorbi
Votes: 15
Popularity: 0.000153
First Submitted: 2020-05-01 19:31 (UTC)
Last Updated: 2023-12-22 11:59 (UTC)

Dependencies (18)

Required by (0)

Sources (4)

Pinned Comments

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

pha-qu commented on 2020-06-15 18:17 (UTC)

@letso .. apologies for the delayed reply. Thanks for pointing out the issue with symlinking to a specific Java implementation. The upstream support for Oracle flavoured Java only somewhat undermines their opensource/cross-platform credentials, but this has become increasingly common in the wider world and the AUR repo. It doesn't however forbid the use of openJDK, and frankly the compatibility of openJDK with processing has improved immensely in recent times. Failures with 3D oriented code and processing used to be commonplace, I've checked a fair portion of the 3D examples, and didn't see any of the old errors that used to plague processing. I'll guess that's a consequence of continuous improvements in the openJVM implementation. I've also noted fully functioning audio examples too, from the beads library, that was a no-no not so long ago, but I do have Jack and Pulse living side by side.

letorbi commented on 2020-06-14 18:51 (UTC) (edited on 2020-06-14 18:51 (UTC) by letorbi)

@lesto Yeah, I had that infinite-loop as well, but I was able to fix it by deriving the JDK-path from the result of which java in the /us/bin/processing and /user/bin/processing-java scripts. However, I'm not 100% sure why this fixes the problem ;)

A patch-file that modifies the scripts accordingly is also part of the processing-jdk8 repo.

lesto commented on 2020-06-14 13:15 (UTC)

@letorbi i did try your same trick the other day and had an infinite loop of java being launched, but probably i did some mistake in the script; the only difference I see you use "which java" instead of "java", or maybe i did some spelling mistake. Ill try your script and if it work I will backport it.

letorbi commented on 2020-06-13 13:14 (UTC) (edited on 2020-06-13 13:27 (UTC) by letorbi)

@lesto I was finally able to find a way to make Processing use the default Java environment without linking /usr/share/processing/java/bin/java to /usr/bin/java. This makes it possible to force Processing to use java-8-jdk or java-8-openjdk while the default Java environment could be a more modern one.

Apart from that I've also created patches for some other improvements. I've updated the processing-jdk8 package already, so I guess you could clone its repo and use it as a base for the processing package. You just have to revert the JDK8 related commits (aa09291, d757116, 892bf4f and 8bc4c89).

...or just pick the changes you want and integrate them into your repo ;)

letorbi commented on 2020-06-11 17:33 (UTC) (edited on 2020-06-12 14:29 (UTC) by letorbi)

@lesto I've just tested your proposed solution with the symlink from /usr/share/processing/java/bin/java to /usr/bin/java again and it seems to work now. Processing uses the default Java environment. Also the problem that @pha-qu described, does not appear anymore.

Unfortunately the "trick" to launch an application with a non-default java version doesn't work. This would be very handy to make Processing use Oracle's JDK, while all other applications could use an OpenJDK environment.

I'll continue to try to find a way how this could be achieved.

letorbi commented on 2020-06-11 09:09 (UTC)

@rhysperry111 Actually my package won't work without jdk8, because it links /usr/share/processing/java to /usr/lib/jvm/java-8-jdk/. See my previous post for reasons why.

BTW: I think it is better to move the discussion to the processing-jdk8 package, if you have further suggestions.

letorbi commented on 2020-06-11 09:05 (UTC) (edited on 2020-06-12 14:29 (UTC) by letorbi)

@lesto Great that you'll take look into my package. And just to mention it: processing-jdk8 is not meant as a replacement, but just as an alternative, for processing (see my previous post).

  • I like the idea of having a reference package. Maybe it is possible to create some kind of -git package based on the processing-docs repo?
  • I think the processing package needs JavaFX, since most installs will use OpenJDK.
  • It would be great, if a user could pick one of the installed Java environments to be used with processing.
    • However, I've tried to achieve that yesterday, but without success - that's why I've created the -jdk8 package in the end.
    • The crux seems to be that processing requires a full JRE at /usr/share/processing/java/ (edit: wrong, see my comment above).
    • The processing package links /usr/share/processing/java/ to /usr/lib/jvm/java-8-openjdk/, so it should only work with jdk8-openjdk right now.
  • Maybe it makes sense to integrate the OpenJDK 11 / OpenJFX support Pull-Request into this package to improve compatibility with OpenJDK.

That it from my side for now. I'm looking forward to hear from you :)

rhysperry111 commented on 2020-06-11 08:51 (UTC) (edited on 2020-06-11 08:53 (UTC) by rhysperry111)

@letorbi I think the best way to do this would be to leave the dependecies as is (so users are not forced to use oracle), but add a strict warning to users when the package is built. This could be done by adding something like this to the PKGBUILD (with some fancy colors):

prepare(){
  echo -e '\033[1;31mWARNING:\033[0m \033[0;33mOnly the official Oracle JDK (version 8) is supported by upstream.\n         Any errors experienced when using the non-Oracle JDK are considered invalid\033[0m\033[0m'
}

letorbi commented on 2020-06-11 08:39 (UTC)

@pha-qu I totally see why you don't want to install Oracle's JDK8. I myself am not happy with it, but since it's the only version, that is officially supported by the Processing developers, I think it is a good idea to have a package that ensures that JDK8 is used. This could help people that have to deal with OpenJDK specific problems.

lesto commented on 2020-06-11 00:10 (UTC) (edited on 2020-06-11 00:14 (UTC) by lesto)

@letorbi I will totally take a look into your variant, but notice dependency is java-runtime=8, so you should be already able to just install jdk8 with this package (see the answer to @pha-qu)

I have currently plan to:

  • move the "reference" to an optional package (the docs are not properly version tracked, so they WILL break when updated, and there is no way for me they released)
  • change the message to suggest to use the same version as bundled with processing (and eventually provide it)
  • I notice you dont depend from JavaFX for build, so I guess I can remove it too

@pha-qu I see, /usr/lib/jvm/java-8-openjdk/bin/java is from jdk8-openjdk /usr/lib/jvm/java-8-openjdk/jre/bin/java is from jre8-openjdk-headless

this build explicitly link to /usr/lib/jvm/java-8-openjdk/ witch basically break all other alternative packages (processing hardcoded look into /usr/share/processing/java/bin/java, also the command line and preference option to disable embedded java does not seems to work)

I think the best solution is to link the generic java binary with

ln -s /usr/bin/java /usr/share/processing/java/bin/java

and then let the user select the desired runtime with archlinux-java; problem is, processing will start but print a quite generic error if started with jdk14.

as alternative i could pick up what archlinux-java does to list the virtual machine installed, and use the first "java-8-*" result, this SHOULD work for all the jre/jdk

@Ectalite no plan to maintain the -git version, feel free to go for it :)