Hittin' the edge cases

One of the applications I develop at Sun uses quite complex process of getting the data from the database. One of the parts is a JNLP application with Swing GUI which presents the data to the user. To get the data it executes the web service method with a parameter which defines the query name. For each query name there exists a script-like definition of the database query which is transformed by the web service into a SQL query. To make the things even more interesting, the web service can execute some Ruby scripts to transform/produce that query. Then it queries the database and returns the data set to the JNLP application.

Everything worked fine until some environment change was introduced: I tried to run the web service on my development machine to avoid testing the application on the production servers. It didn't produce the query and the error messages were rather cryptic. After some investigation my colleague found the reason: the Ruby scripts which were executed to produce the query were executed from the network share as simple UNIX executable files and they had a specific shebang line in the beginning of the file to specify which interpreter to run:

#!/net/some.server/path/to/ruby

It worked well for a lot of situations, but it didn't work for me: my development machine has the i386 architecture and it is running Debian GNU/Linux, but some.server was a Solaris SPARC server, and ruby is a binary executable. It was possible to work around the problem by various ugly methods, such as hardcoding the paths of the interpreter in the web service and choosing the correct one based on the host, changing the shebangs so that they pointed to the link to ruby which should be present on all the servers which need to run the scripts, etc. But after some time it occurred to me that I could simply use JRuby in the web service and thus not risk making problems to other users of the scripts.

First I thought of using the Bean Shell Framework (because of some GlassFish on JDK6 problems I can't use JDK6 and thus its scripting support), but I needed to get the data from the standard output of the script and this wasn't possible to do from the BSF. Then I looked at the Main class of JRuby and found that it was just the thing which I needed: it is possible to pass which Streams to use as stdin, stdout and stderr. I made some really small changes to the web service to make it call JRuby engine instead of creating the external process and it worked! I really feel the benefit of using the JRuby in such situation: running in heterogeneous environment is what Java is suited for, and hence what JRuby is suited for it too.