prevent rJava multi-arch installation check errors

[petermeissner]

The steps described to prevent check problems related to packages using rJava on Windows in the current README are not sufficient.

I added the description of a fix for an (additional) rJava check problem case.

See here for the minimal package:

• https://ci.appveyor.com/project/petermeissner/javahelloworld/history
• https://travis-ci.org/petermeissner/javahelloworld/builds
• https://github.com/petermeissner/javahelloworld

[krlmlr]

Thanks. Is it possible to install Java on the "other" platform in AppVeyor, to avoid the check errors?

[petermeissner]

Two thoughts:

1.) According to this page a lot of Java version should already be installed including 32-bit and 64-bit: https://www.appveyor.com/docs/windows-images-software/#java.

• Now the question would be can we make the installation checks use the right version somehow.
• I have no idea how to approach this.
• (I can try to install a 32-bit Java on my local machine and than have a look if the check still fails for multi-arch or if this solves the issue)

2.) From a practical standpoint one might ask: Does it matter? Is it worth the effort?

• Multi-arch installation seems somewhat outdated.
• The important platform type is 64-bit, this one is tested and this one is passing.
• Furthermore, only installation checks fail and one could argue that its more a thing users should get right than those building the packages?.

[petermeissner]

Digging a little bit into this ...

• installation checks fail on local with and without Java installed for both platforms
• for 32-bit R loading rJava fails because JAVA_HOME environment variable points to 64-bit Java version
• using e.g. Sys.setenv(JAVA_HOME = "C:\\Program Files (x86)\\Java\\jre1.8.0_231") and then loading rJava works

• I am not sure how to make this work automatically for both versions and if this then really fixes the installation check problems
• something like a JAVA_HOME_32 and JAVA_HOME_64 would have been handy to have

[krlmlr]

@FeodorFitsner: Any thoughts regarding the setting of the JAVA_HOME environment variable for testing 32-bit processes?

[petermeissner]

Digging more ...

• There is advise that rJava should pick up the right Java version if installed ...

  • here https://r.789695.n4.nabble.com/rJava-works-with-32-bit-but-not-64-td4657451.html
  • and here https://stackoverflow.com/a/7604469/1144966
  • I tried it it does not change a thing

• Now there is also advise to remove the setting for JAVA_HOME altogether

  • here https://stackoverflow.com/a/15998358/1144966
  • this one actually works if done in the .onLoad() function of the package like in the example below
  • ... at least locally with different version of R (3.5.2, 3.6.2) building and checking from 32-bit and from 64-bit but not on Appveyor (see failure here)

.onLoad <- function(libname, pkgname) {

  # let rJava find right Java version on its own
  Sys.setenv(JAVA_HOME = "")

 # initialize package jars
  rJava::.jpackage(pkgname, jars = "*", lib.loc = libname)
  rJava::.jaddClassPath(
    list.files(
      system.file("java", package = "javahelloworld")
    )
  )

}

So, maybe we have two problems?

1. An rJava problem - namely not picking up the right Java versions anymore: issue 204, issue 2013
2. An Appveyor problem: there might be no 32-bit Java version be installed after all? https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

[FeodorFitsner]

@krlmlr There is Java 8 x86 pre-installed on build workers: https://www.appveyor.com/docs/windows-images-software/#java. It's in C:\Program Files (x86)\Java\jdk1.8.0, however, if I'm not mistaken path in JAVA_HOME should be in DOS 8.3 format, so you have to figure it out.

[krlmlr]

@petermeissner: Could you try to RDP into the worker and see what's happening inside? https://www.appveyor.com/docs/how-to/rdp-to-build-worker/

[petermeissner]

I added the error message. The section now has the

• error message
• technical description of the problem
• a working solution

The whole thing now reads as follows ...