Repository navigation
Cannot reload rJava after detaching #249
Description
Activity
Version 0.9-13 uses (optionally) dynamic loading of JVM library so it cannot be unloaded since the JVM is loaded directly into R instead of rJava linking to JVM (this is the default on macOS to allow fo dynamic location of the JDK). I'm not sure if this is the cause, but rJava was never designed to support unloading, because JVM cannot be initialised twice anyway. The only thing we could do is to not load JVM until
.jinit()which is the point of no return. What is the purpose of trying to detach rJava if it can not be detached once used anyway?The motivation was driven by the fact that it's not possible to use the XLConnect package and the xlsx package in the same R session, I believe since they both depend on rJava. By "same R session", I don't mean concurrently, since I know they will conflict, but just loading one package, then detaching it, and loading the other package. That still doesn't work, but I thought by detaching and reloading rJava it would solve the problem. It sounds like it wouldn't necessarily work anyway, in which case I'll just have to work around it by starting a new session if I need to use the second Excel package.
You can use arbitrarily many packages that depend on rJava, there is no limit at all, so I don't see a reason why they shouldn't work. However, once you load any Java code you cannot unload the JVM so what you were trying to do won't work either way. You have to re-start the R process in order to start a new JVM.
Thanks for clarifying. These are the two issues from a few years ago that say the two Excel packages can't be used in the same session because they share a Java dependency: miraisolutions/xlconnect#79 and colearendt/xlsx#95
If I understand correctly, you're saying there's no reason why both packages couldn't be loaded and used concurrently? In any case, since this isn't an issue with rJava, I'll close the issue.
@Mosk915 Ok, got it, so the issue is likely that they use the exactly same class, but each of them has a different version of it (from a different JAR file). In principle that is actually a solvable problem, because rJava has control over the class loader, so it could use separate class loaders for each package. Currently, rJava uses a global class loader, but it is in principle possible to do something like the namespaces in R where a package would register its own class loader and use it when calling its classes. This will require co-operation of the packages, but probably worthwhile to avoid cases like the above.
That's good to hear it's solvable. Thanks so much for looking into it and for the quick responses.
Just for the record since this was just referenced: since rJava 1.0 packages can use package-private class loaders (see
own.loader=TRUEargument in.jpackage()) which guarantees that each package is isolated from any other packages and thus the problem referenced here (two packages loading conflicting classes in one session) is solved by that feature.
When using version 0.9-13 of rJava, trying to reload the package after detaching it results in an error. This does not occur in version 0.9-12.