R CMD javareconf -e resetting conda environment to base

[djconly85]

I am trying to run the r5r package using java version 21 on a Linux-based high-performace cluster (HPC).

Following the quick-start guide instructions, I tried the following:

1. Set miniconda environment to desired env, named acc_tool.
2. Open R console
3. Run java_quick_install(version = 21) successfully, with following output:

> java_quick_install(version=21)
Detected platform: linux
Detected architecture: x64
You can change the platform and architecture by specifying the `platform` and
`arch` arguments.
Downloading Java 21 (Corretto) for linux x64 to
/home/dconly/.cache/R/rJavaEnv/distrib/amazon-corretto-21-x64-linux-jdk.tar.gz
File already exists. Skipping download.
Java distribution amazon-corretto-21-x64-linux-jdk.tar.gz already unpacked at
/home/dconly/.cache/R/rJavaEnv/installed/linux/x64/21
✔ Current R Session: JAVA_HOME and PATH set to /home/dconly/.cache/R/rJavaEnv/installed/linux/x64/21                                                                                               
✔ Current R Project/Working Directory: JAVA_HOME and PATH set to '/home/dconly/.cache/R/rJavaEnv/installed/linux/x64/21' in .Rprofile at '/home/dconly/acctool_files'                                                                                                             
Java 21 (amazon-corretto-21-x64-linux-jdk.tar.gz) for linux x64 installed at
/home/dconly/.cache/R/rJavaEnv/installed/linux/x64/21 and symlinked to
/home/dconly/acctool_files/rjavaenv/linux/x64/21

4. Quit R and return to command console
5. In command console, enter R CMD javareconf -e, specifying the -e flag since I am not a root/admin user. This returns the following:

(acc_tool) [dconly@mmb77 acctool_files]$ R CMD javareconf -e
Java interpreter : /home/dconly/miniconda3/envs/acc_tool/lib/jvm/bin/java
Java version     : 23.0.1-internal
Java home path   : /home/dconly/miniconda3/envs/acc_tool/lib/jvm
Java compiler    : /home/dconly/miniconda3/envs/acc_tool/lib/jvm/bin/javac
Java headers gen.: /usr/bin/javah
Java archive tool: /home/dconly/miniconda3/envs/acc_tool/lib/jvm/bin/jar

trying to compile and link a JNI program
detected JNI cpp flags    : -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
using C compiler: ‘x86_64-conda-linux-gnu-cc (conda-forge gcc 14.2.0-1) 14.2.0’
x86_64-conda-linux-gnu-cc -I"/home/dconly/miniconda3/envs/acc_tool/lib/R/include" -DNDEBUG -I/home/dconly/miniconda3/envs/acc_tool/lib/jvm/include -I/home/dconly/miniconda3/envs/acc_tool/lib/jvm/include/linux  -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /home/dconly/miniconda3/envs/acc_tool/include -I/home/dconly/miniconda3/envs/acc_tool/include -Wl,-rpath-link,/home/dconly/miniconda3/envs/acc_tool/lib    -fpic  -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/dconly/miniconda3/envs/acc_tool/include -fdebug-prefix-map=/home/conda/feedstock_root/build_artifacts/r-base-split_1734346517311/work=/usr/local/src/conda/r-base-4.3.3 -fdebug-prefix-map=/home/dconly/miniconda3/envs/acc_tool=/usr/local/src/conda-prefix  -c conftest.c -o conftest.o
x86_64-conda-linux-gnu-cc -shared -L/home/dconly/miniconda3/envs/acc_tool/lib/R/lib -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -Wl,--allow-shlib-undefined -Wl,-rpath,/home/dconly/miniconda3/envs/acc_tool/lib -Wl,-rpath-link,/home/dconly/miniconda3/envs/acc_tool/lib -L/home/dconly/miniconda3/envs/acc_tool/lib -o conftest.so conftest.o -L/home/dconly/miniconda3/envs/acc_tool/lib/jvm/lib/server -ljvm -L/home/dconly/miniconda3/envs/acc_tool/lib/R/lib -lR

The following Java variables have been exported:
JAVA_HOME JAVA JAVAC JAVAH JAR JAVA_LIBS JAVA_CPPFLAGS JAVA_LD_LIBRARY_PATH
Running: /bin/bash
Removing compiler version 2023.2.1
Use `module list` to view any remaining dependent modules.
  Load "debugger" to debug DPC++ applications with the gdb-oneapi debugger.
  Load "dpl" for additional DPC++ APIs: https://github.com/oneapi-src/oneDPL
Removing mkl version 2023.2.0
Use `module list` to view any remaining dependent modules.
Removing tbb version 2021.10.0
Use `module list` to view any remaining dependent modules.
Removing compiler-rt version 2023.2.1
Use `module list` to view any remaining dependent modules.
Removing oclfpga version 2023.2.1
Use `module list` to view any remaining dependent modules.
Loading compiler version 2023.2.1
Loading tbb version 2021.10.0
Loading compiler-rt version 2023.2.1
Loading oclfpga version 2023.2.1
  Load "debugger" to debug DPC++ applications with the gdb-oneapi debugger.
  Load "dpl" for additional DPC++ APIs: https://github.com/oneapi-src/oneDPL
Loading mkl version 2023.2.0
(base) [dconly@mmb77 acctool_files]$ 

6. However, running javareconf -e reset my conda env back to the base, not the acc_tool env I want to use.
7. Nonetheless, as a test I open the R console in the base env and enter java_check_version_rjava() and get what I think is the correct output:

> java_check_version_rjava()
Using current session's JAVA_HOME: /home/dconly/.cache/R/rJavaEnv/installed/linux/x64/21
With the user-specified JAVA_HOME rJava and other rJava/Java-based packages will use Java version: "1.8.0_482"
[1] "8"

8. But as said above, I want to be in the acc_tool env, not the base env, so I exit R, activate the acc_tool env, re-open R, then run the java_check_version_rjava() command, but this time I get an error saying rJava package is not installed, like so:

> java_check_version_rjava()
✖ rJava package is not installed. You need to install rJava to use this function to check if rJava-based packages will work with the specified Java version.
[1] FALSE

To summarize, I need to run R CMD javareconf -e in order to get a successful check running the java_check_version_rjava() command, but running the javareconf also forces my conda environment back to base. But if I then set it back to the desired acc_tool env, I get the rJava package is not installed error.

Have you seen this before?

Thank you in advance,

PS - some additional info
I am running Linux "Rocky Linux" version 8.7

If I just run java -version from the command, it looks like there is a version 23 installed. I am not sure if this would affect my ability to use version 21 for my r5r application, but I figured I'd mention it. Here's exact output:

(acc_tool) [dconly@mmb77 acctool_files]$ java -version
openjdk version "23.0.1-internal" 2024-10-15
OpenJDK Runtime Environment (build 23.0.1-internal-adhoc.conda.src)
OpenJDK 64-Bit Server VM (build 23.0.1-internal-adhoc.conda.src, mixed mode, sharing)

[e-kotov]

@djconly85 hi, and sorry for late reply.

I am also using r5r on HPC cluster, so I think I will be able to help you and fix bugs in the package if any.

I will have a look later this week.

1. Are you using it in a Rocky Linux container via Singularity/Apptainer or are you running on one of the compute nodes directly?
2. Are you using latest CRAN version of rJavaEnv (0.3) or are you using the dev version form GitHub?
3. Same as 2 for r5r - which version are you using, latest CRAN or dev from their GitHub repo?

[djconly85]

To answer your questions:

1. I'm not familiar with Apptainer/Singularity. Based on a quick googling of what those are, I'm 99% sure I'm not doing so.
2. I am using the latest CRAN version (0.3.0) of rJavaEnv
3. For r5r, I am using version 2.3.0, downloaded via CRAN

Also some potentially useful information: While I have not resolved this specific issue, I was able to get java_check_version_rjava() to work correctly if, in the command line, I first entered export LD_LIBRARY_PATH=/home/dconly/.cache/R/rJavaEnv/installed/linux/x64/21/lib/server:$LD_LIBRARY_PATH before opening R. Importantly, I can also successfully run r5r analyses if I run this command first.

So in terms of my personal project needs, I am good to go by using the export command, but if you want to get to the bottom of this specific issue, let me know if there's any other information I can provide.