I was asked to summarize my experiences with starting up a project with JRuby, so I’ll do so here.
Overall I have been very impressed with JRuby, which I’m finding to be an excellent way to leverage the cleanliness of Ruby code with Java libraries, in my case, Swing, in the above two projects. I am also working on prototyping the new Javadoc processor for DoctorJ, writing it with a regular expression in Ruby, which I will migrate over to pure Java, but one chunk of code at a time via JRuby. My earlier rewrite went poorly, since without using JRuby as a bridge, I had to convert Ruby code straight to Java, which was too drastic of a change to go well. And it didn’t.
JRuby is so much like Ruby that the differences are surprising. As I wrote before, Ruby gems are not JRuby gems. Java threads behave poorly with Ruby threads, and I found it easier to use only Java threads.
In Swing, there are issues setting a JFrame as full-screen via the extended state and undecorated attributes, such as (in a subclass of JFrame):
set_extended_state JFrame::MAXIMIZED_BOTH set_undecorated true
In Linux, this works properly in Java 1.6, but not in Java 1.5. In Windows, it does not work correctly with neither Java 1.5 nor 1.6.
Distributing a JRuby program is easy, although I wish (as with many programming languages and environments) that an installer was more integrated with the language. The best solution I found was to jar the complete JRuby jarfile with my *.class and *.rb files, with the manifest (META-INF/MANIFEST.MF) contents as “Main-Class: MyAppMain”.
MyAppMain is the JRuby equivalent of the Java main class, annotated as a Java class, such as:
class MackworthTestMain java_signature 'void main(String)' def self.main args MackworthTestFrame.new end end