In ruby-processing https://github.com/jashkenas/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 http://www.ruby-forum.com/topic/4414925#new, 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 be that I need to explicitly need to do something in the case of regular JRuby, that gets done automatically with JRuby-Complete?
on 2013-06-21 07:32
on 2013-06-22 19:50
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 that. 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
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:- https://github.com/jashkenas/ruby-processing/tree/... 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:- https://github.com/jashkenas/ruby-processing/blob/... 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'.
on 2013-06-23 16:54
Here is error message generated with a GLSL shader sketch run with an external Jruby https://gist.github.com/monkstone/5845285
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 http://www.compoundtheory.com/, which seems to have no difficulty running shader sketches with regular JRuby.