Calling R from Java using JDeveloper

Download: rJava0.7 from http://www.rforge.net/rJava/files/

Extract from “rJava 0.7\rJava\jri\JRI.jar” and put the .class files inside your project. Still not able to compile, also add the JRI.jar file to the library path (for compilation purposes):

For the sake of convenience, put “import org.rosuda.JRI.*;” everywhere although every class specifically mentioned is better of course.

Now, a more common error is shown on the console when trying to use the R engine:

Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
java.lang.UnsatisfiedLinkError: no jri in java.library.path

Obviously the JRI.jar is not on the library path (but the swing application contains it -they should work on that).

Still, on any client ‘R’ will be installed; which contains the JRI.jar if rJava gets installed. So, let’s do that first, It is adviced to use version 2.9, so let’s do a full-install with 2.9.1 (if that will fail, we try 2.9.0).

In Vista, install it in the user environment as administrator:

Then set R_HOME to the proper location and add R_HOME/bin to the Windows path:

Although this should work immediately, the paranoia mode is fully operational, so reboot first.

After a reboot, run ‘R’ and install rJava using this command:

install.packages('rJava',,'http://www.rforge.net/')

Now the JRI.jar should be in the library/rJava/jri directory and it should be the same (hopefully) as in the JDeveloper project(!). This part is rather buggy in my optinion, since we only can assume the intall.packages command uses exactly the same as the version in the files section mentioned in the very first line of this post.

The ‘UnsatisfiedLinkError’ is still there when running a test from JDeveloper, so after some googling the native DLLs must be on the system path as well, in this case the jri.dll (pretty clear exception, not). This is an important step for the installation manual.

When the R_HOME/library/rJava/jri is added to the system path, the test from inside JDeveloper works! Now let’s go for a deployment on another machine. It is clear, the development machine is a bit more intelligent than one without a Java SDK (only JRE 1.6 is required). When all system variables are set correctly (nu user environment variable), all works nicely.

For the future; not to include the JRI.jar inside the deployment.

Unable to create new class in JDeveloper running Vista

When you run JDeveloper on Windows Vista you might run into several security issues. Sometimes the only solution is to turn off UAC (User Account Control). For me, it was best to install JDeveloper into my own user space, also add javadocs locally there and change the library lookups.

But at some point I was unable to create a new Java class file (on a package, right-click and select ‘new’). This was odd. After some thinking I decided to change the look and feel in the preferences back to ‘Oracle’ style instead of ‘Windows’ style. And indeed, rare but true, it worked again! UAC could be turned on again.