FAQ for the R-Java Interface

1. Starting the Java Virtual Machine
2. Performance
3. Method Identification

Starting the Java Virtual Machine

When I load the shared library (Java.so) I get errors about not being able to load a shared library or undefined symbols. What's the problem?

Most likely, you do not have the environment/shell variable LD_LIBRARY_PATH set correctly. Source one of the RJava.csh or RJava.bash scripts that are created during the configuration of the R-Java package. To find them, run the R command

   system.file("scripts/RJava.csh", pkg="Java") 

The first is for use within C shells (csh and tcsh) and the latter for use with the Bourne shell (sh, bash). This must be done before starting R.

These scripts append the appropriate directories to one's LD_LIBRARY_PATH variable and makes . the Java libraries and support library in the R package for Java available to the dynamic loader.

When I call .JavaInit(), the prompt never returns. Any solution?

We have seen this on Linux with IBM's JDK1.3. The problem is that when loading the shared library (Java.so) one must specify FALSE as the value for local. That is

        dyn.load("Java.so", local=FALSE)
      

The automatic configuration attempts to get this correct and put the appropriate call in .First.lib.

On Solaris, when I initialize the Java Virtual Machine, I get a paragraph about needing to apply some patches. Do I really have to install these?

The solution answer again lies with the way dyn.load() is called. Make certain that the Java.so shared library is loaded with the argument local=FALSE.

When I try to do anything that involves the class RForeignReference, Java complains about not being able to load a library named Java.so and prints a huge call-stack trace.

The problem is due to one of two things. Perhaps you have not set your LD_LIBRARY_PATH variable correctly.
More likely however is that when you installed the package, you did not give the R INSTALL command the -c (or --clean) argument. This is necessary as it tidies the installation up after everything is compiled and made available to R. This creates a symbolic link in the Java/libs directory that connects Java.so expected by R to libJava.so expected by the Java virtual machine. In other words, this issues the command

ln -s Java.so libJava.so      
      

in the Java/libs directory. A script - cleanup - will do this for you. It is located in the Java/scripts directory where the library was installed.

Why do we have to explicitly run .JavaInit() ? It seems like a waste of time after the library call.

From Tony Rossini:
Because you only get one chance per R session to add directories or jars to the classpath, set the library path and start up the Omegahat interpreter (almost!).

I forgot to start the JVM (i.e. call .JavaInit()) before calling one of the functions that needed it. Now when I call .JavaInit() after this, it hangs?

Yep. This appears to be a problem with some operating systems and Java implementations. It is likely that this is a problem with threads and synchronization. I am not certain how to handle it at this stage. See the Bug list.

Performance

Why is the first call to .Java() or .JavaConstructor so slow?

Because, the default setup for the Omegahat interpreter allows the user to specify partially qualified class names. To do this, the Omegahat interpreter must read every element in the classpath and construct a list of all the classes in all the sub-directories of those elements. This takes time!

This lengthy class list construction can be reduced (or eliminated). Firstly, use fully-qualified class names. This makes the code more readable, but it is tedious.
An alternative is to tell Omegahat which classpath elements for which it should construct the class lists. This list is specified via the JVM property OmegahatClassLists

 javaConfig(OmegahatClassLists="./myclasses:/home/me/Java/classes.jar")

See The Omegahat Howto.

Method Identification

Why do I get anonymous references that have class MethodAlias?

This means that the .Java call couldn't resolve a real Java method, but got one that had the same name and number of arguments. One of the most common causes for this in R is when one specifies an integer constant (e.g. 0) but it is passed to Java as a double/numeric. For example

 v <- .JavaConstructor("util.Vector", 3)

The three here is actually of more numeric.

This behaviour is part of R and S3 and unfortunately we are stuck with it. (A lot of the R code (especially Fortran associated) breaks if this is changed. It does not happen in S4.)