Errors on run : Unhandled Java exception

[ruby-processing]

Errors on run : Unhandled Java exception

[monkstone]

Hi @sampottinger I used the code to compile my own processing core. I have yet get confirmation that it works on MacOS. However from @Aerlinger comments propane, that uses essentially same code works. Unlike processing.org I do not use antlr pre-processor, and I have time to test code, and I don,t use my jdk. This means change to jdk11 is more urgent for my projects.

[monkstone]

I can get JRubyArt to run OK on linux with openjdk10, but I have good reason to believe that com/apple/eawt/QuitHandler failure has several possible causes:-

1. The apple.jar needs to be on the classpath on the Mac (and it isn't).
2. Java fails to see the proprietary code (which goes back to the last Mac JVM 1.6).

What I can say is that when I attempted to compile java processing with jdk9 it refused to do so because of the proprietary code, even with apple.jar on classpath. You can try adding https://github.com/processing/processing/blob/master/core/apple.jar to the classpath possibly by adding it to the lib folder of the JRubyArt gem.

At present processing.org have no intention of supporting greater that jdk8.

PS: I'm going out for a bit chances are I won't be able to reply until Saturday 8th.

[tomstuder]

@monkstone Not a problem. Thank you for reviewing. Please let me know if you need any references to my current setup. I am on mac OS Sierra 10.12.6 (16G1510).

[monkstone]

@tomstuder I'm a bit worried by your tweet that you have both processing-2.2.1 and processing-3.4 installed, because I'm not sure how it works on Mac (on most linux installs they can easily co-exist owing to the versioning, except you need two sketchbook folders, typically at /home/tux/sketchbook and /home/tux/sketchbook3). For processing-2.2.1 there is ruby-processing, but it's not maintained, JRubyArt was created as replacement for ruby-processing since processing-3.*. Anyway if the processing installs both work for you it doesn't matter, but what it does mean for you is that you can't rely on my default configurations for the Mac.

~.rp5rc for ruby-processing

PROCESSING_ROOT: "/Applications/Processing.app/Contents/Java
...

.jruby_art/config.yml for JRubyArt

Note that if you wan't to use an installed jruby instead of jruby-complete set JRUBY: true

PROCESSING_ROOT: /Applications/Processing.app/Contents/Java
sketchbook_path: # user defined path, to pick up video/audio libraries etc
JRUBY: false # uses jruby-complete by default for running sketches
template: bare # use class or emacs for alternative templates

The PROCESSING_ROOT needs to point to the outer folder where processing has been installed (when we automagically can pick up processing core.jar etc and stick them on java classpath) and not symbolic links as it will be if you installed using brew.

See #28

Sketchbook Path for Mac OS X, it's Users → username → Library → Processing
(you need sketchbook path to access the java libraries eg sound, video)

As you might have guessed I'm in UK and running on BST (GMT+1) and a bit of an early bird.

[monkstone]

@tomstuder Re jdk10, it is quite possible that jdk8 on MacOS contains the proprietary code (it certainly can help to make awt swing work better on the Mac, since Mac stopped providing there own version of jvm). In which case jdk10 might work with processing/JRubyArt if processing.org apple.jar was on the classpath.

[Aerlinger]

Having the exact same issue with JDK12 on mac OS Sierra 10.14.3. Tried using other versions of the JDK but going in circles and can't seem to get past this issue. Has anyone found a solution?

[monkstone]

The current version of processing is not compatible with jdk9+, especially on macOS. Sam Pottinger has a branch that works with jdk11. Further I have compiled and run JRubyArt with it on linux. If you are up to it, it would be great to see if it works on macOS. https://github....sampottinger/processing. Failing that try the latest version of propane.

[Aerlinger]

Thanks for the quick response. Using propane appears to work fine for me.

Is there any disadvantage to using propane vs JRubyArt other than watch not being available? I'm not using the processing editor for development and JRubyArt seems to use a bit more "magic" to be similar to processing (i.e. declaring setup, draw, etc. in the global namespace). I did notice that some of the Propane examples (e.g. circles) are different so wasn't sure which one was best to use.

[Aerlinger]

It's also unclear if processing libraries such as Sound/Video can be used from Propane. Looking deeper it looks like the documentation on Propane is almost identical to JRubyArt.

Is it safe to say that JRubyArt is essentially a wrapper around Propane that abstracts away some of the details of JRuby and also provides an interface to processing?

[monkstone]

See how to use the processing libraries and other libraries. For processing libraries they need to be installed, this can be done manually as well. JRubyArt is quite different from propane, in that there is two stage load process, this is partly what allows us to support watch mode it is very much a successor to the original ruby-processing, and relies on an installed version of vanilla processing, we pick up processing jar locations (core.jar etc. and libraries jars) via configuration. For propane we compile our own processing core from source and stick it it with our custom code into propane.jar. We rely on a path convention to use other processing libraries, so we need to install them ourselves. The load_library alias load_libraries allows us to load pure ruby and pure java libraries (similar for both JRubyArt and propane). There's more, certain processing libraries toxiclibs, geomerative and wordcram are available as gems, plus certain custom libraries these libraries need only be required to use with either JRubyArt or propane.
There is a lot of common code between JRubyArt and propane but they are different. Currently we only support class wrapped sketches on propane, on JRubyArt we support naked, bare and class wrapped sketches.

[monkstone]

My first response was written quickly on my tablet, so it was briefer that I would like. I would very much like to get to bottom of issue with JRubyArt on macOS. But if we wait for Ben Fry to sort it out, hell may well have frozen over. Sam Pottinger has done a brilliant job of updating vanilla processing, and it works on linux (but also must work on macOS, because that's what he developed it on. If you are happy with propane all well and good, but make sure to post any issues to https://github.com/ruby-processing/propane/issues. The current version of JRubyArt should work with Sam Pottingers version of processing (needs ant compile) providing that you point to correct PROCESSING_HOME.

[monkstone]

OK it seems Ben Fry is going to drag his feet here, because he's no longer paying attention to Sam Pottingers pull request. A possible solution is to compile our own processing core (as was done in early versions of ruby-processing) see https://github.com/monkstone/processing-core.

[monkstone]

@tomstuder @Aerlinger is there any chance you could test jruby_art-2.0.0.pre for me, that I have just released to https://rubygems.org/gems/jruby_art, it is compiled with jdk11 and includes fixes that should make it compatible with macOS. PS it does not rely on an installed vanilla processing.

gem install jruby_art --pre

[monkstone]

If SamPottingers fix does not work, does this make sense https://alvinalexander.com/source-code/java-macos-about-preferences-quit-handlers-desktop-awt ?

[sampottinger]

Hey! Just checking to see what if you had any luck on this issue on your end? Were you able to use my fix?

[monkstone]

Hey that,s utterly spooky, @benfry with health issues I am currently in hospital awaiting probable pacemaker...

[sampottinger]

Ahhh stay healthy processing community! Hope it goes well @monkstone.

[monkstone]

@sampottinger thanks for concern, I am now a bionic man having had ICD fitted for ARVCD (I'm the oldest person to present the condition, in the experience of my consultant, further I was completely asymptomatic, so had many tests to diagnose). @Aerlinger @tomstuder could you please try out the latest JRubyArt prelease:-

gem install jruby_art --pre

That should fix issue (NB: move old ~/.jruby_art/config.yml before installing, new config setup)

[benfry]

@monkstone, insulting and talking s*t about strangers isn't a great way to motivate them to do things for you. Not sure what I've done to you that deserves this kind of talk:

I would very much like to get to bottom of issue with JRubyArt on macOS. But if we wait for Ben Fry to sort it out, hell may well have frozen over.

and

OK it seems Ben Fry is going to drag his feet here, because he's no longer paying attention to Sam Pottingers pull request.

Processing has always been a project I do in my spare time, and give away for free. Cut me some slack when I don't have the time, or at least refrain from dragging my name into your rants.

[monkstone]

@benfry I hope you are well. I know you are probably as frustrated as I am how Apple and Oracle have made it to develop cross-platform open source projects in java. But I think it has been a long time coming. I am sure there are any number of people that would like to help out, and @sampottinger seems to have made an excellent start.

[monkstone]

Should be fixed with JRubyArt-2.0 if it is not please re-open