setting CLASSPATH manually prevents rJava from finding getsp class for configure tests

[DarioS]

Using the command > install.packages("rJava") fails with the message
... ...
checking Java support in R... present:
interpreter : '/usr/bin/java'
archiver : '/usr/bin/jar'
compiler : '/usr/bin/javac'
header prep.: '/usr/bin/javah'
cpp flags : '-I/usr/lib/jvm/java-7-openjdk-amd64/jre/../include'
java libs : '-L/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server -ljvm'
checking whether Java run-time works... Error: Could not find or load main class getsp
no
configure: error: Java interpreter '/usr/bin/java' does not work
ERROR: configuration failed for package ‘rJava’

• removing ‘/home/dario/R/x86_64-pc-linux-gnu-library/3.0/rJava’

I did $ sudo R CMD javareconf and reopened R, but this made no difference. I also clicked the link on the rJava homepage "If you have questions about installation, please visit the R Wiki - rJava package.", but the link is broken.

At the command line, Java is working fine :

dario@bioinfo:$ java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.12) (7u25-2.3.12-4ubuntu3)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
dario@bioinfo:$ which java
/usr/bin/java

[s-u]

It seems that your'e not working off a proper tar ball - did you run mkdist to create a distribution tar ball?

[gitkit7]

I have had the same problem install the package rJava into R-3.1.0 on a Centos 6 environment.
Eventually worked out that my CLASSPATH variable was defined and it NOT include ".". By default java looks in the current directory if CLASSPATH has no value. If it is defined, java does not look in the current directory, hence the class getsp was not found. By defining CLASSPATH using:

export CLASSPATH=.:/my_other_classpath_directory

my installation of the rJava package worked
cheers,

Keith

[s-u]

@gitkit7 thanks! That was indeed the actual issue here. I have added a work-ardound for cases where CLASSPATH is already overridden by the user. Note that setting CLASSPATH will cause issues down the road anyway (it may invoke a different class loader and cause confusion), so it's better to unset it.