Forum: JRuby Different behaviour with JRuby-Complete

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
712effd8673463d44a730bac4cd29311?d=identicon&s=25 Martin Prout (monkstone)
on 2013-06-21 07:32
In ruby-processing I have
found two instances where there is a different behaviour when using
regular jruby-1.7.4, or jruby-complete-1.7.4.

1. When using JRuby-Complete and trying to access a method from an
abstract java class (which for some reason best known to the java
library author is 'protected') I get method missing (the method is
public, but is only defined in the abstract class, ho hum). The method
is 'visible' with regular JRuby, and as with regular processing and java
the method be can used.

2. The second case is when trying to run processing GLSL shader
sketches, in this case the JRuby_Complete runs the sketch fine, whereas
the installed JRuby does not run the sketches. Now this might be similar
to previous topic, but I'm
not sure how? Both regular JRuby will run OPENGL sketches, which means
the native JOGL2 binaries can be accessed (they are in jars). Could it
that I need to explicitly need to do something in the case of regular
JRuby, that gets done automatically with JRuby-Complete?
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-06-22 19:50
(Received via mailing list)
I would guess the problem here is a difference between using JRuby at
the command line and the jruby-complete jar with a Java command line.

In the first case, JRuby loads itself into the boot classpath, for
startup perf reasons. This can in some cases give it additional
privileges. The latter case loads JRuby as a normal userland class at
the "system" classloader level.

As for loading native libraries, the command-line JRuby rewires the
native loading a little big to get our FFI library to load; this may
cause some native libraries to have problems. Otherwise, it could be a
similar issue, since the boot classloader causes all classes loaded
under it to report a null getClassLoader and some libraries blow up on

If you can provide more concrete examples, ideally with something we
can run and error traces, we can help you work around this or try to
fix it on our end if it represents a JRuby issue.

- Charlie
712effd8673463d44a730bac4cd29311?d=identicon&s=25 Martin Prout (monkstone)
on 2013-06-22 20:59
I know it might be asking a lot, but if you could give ruby-processing a
try, there are the shader examples:-
included with ruby-processing that will not run with an external jruby
and run just fine with the included jruby-complete.

An example of the sketches with method missing (with jruby-complete) are
those that require the fisica library:-
But that is a much bigger ask, unless you've already installed
processing, as it requires the fisica library to be installed. To me
this is less interesting, since I would almost expect the method
set_fill to be missing as it is declared public in a lazily protected
abstract class. But it seems regular java processing and the external
jruby are more 'tolerant'.
712effd8673463d44a730bac4cd29311?d=identicon&s=25 Martin Prout (monkstone)
on 2013-06-23 16:54
Here is error message generated with a GLSL shader sketch run with an
external Jruby
712effd8673463d44a730bac4cd29311?d=identicon&s=25 Martin Prout (monkstone)
on 2013-06-27 08:31
Just to be sure, I tested that the correct classpath was being used by
OPENGL sketches whether run using JRuby-Complete or with regular JRuby,
with a simple 'puts $CLASSPATH' both correctly pointed to the folder
containing relevant jars (which in processing wrap the native
libraries). So still no further on. I even experimented with this lwgl
app, which seems to have no difficulty
running shader sketches with regular JRuby.
This topic is locked and can not be replied to.