I want to export the Eclipse project so that it can be used on other computers.
Asked 1 years ago, Updated 1 years ago, 97 viewsI exported the project I made with Eclipse so that it can be used on other computers, but I can't use it on another computer, so please tell me why.
I will use JRI for the project, so I will leave a program that will give you 6.0 when compiled as an example.
import org.rosuda.JRI.REXP;
import org.rosuda.JRI.Rengine;
public class JriTest
{
public static void main (String[]args)
{
Engine engine = new Engine (new String[]{"--no-save"}, false, null);
engine.assign("a", new int[]{36});
REXP result=engine.eval("sqrt(a)");
System.out.println(result.asDouble());
engine.end();
}
}
Build Path and Run Configuration are as follows:
I tried this on my computer's CMD, but it didn't start like above, so I asked Another question and they told me to manipulate the environment variables, so I added the following to PATH
C:\R\R-4.0.0\library\rJava\jri\x64
Then the value was 6.0.
The question I would like to ask is whether there is a way to export this PATH without configuring it.Is it possible to include all PATH information in the project when exporting?Also, how can I use it even if the receiver does not install rJava and JRI?I would appreciate it if you could let me know.
java r eclipse
1 Answers
rJava is intended to use Java from R, and I don't think installation is required to execute the code in question.
JRI is for using R from Java and is required.
JRI is implemented with JNI and requires a native library (jri.dll for JRI).
The native library must be on the file system (not as a resource in jar) and must be located in the directory specified by the system property java.library.path and environment variable PATH (for Windows).
In other words, if you want to execute the code in the questionnaire (after setting up the Java and R environments),
jri.dllsomewhere- Tell the program where you put it
is required.
(To be exact, putting jri.dll in the default library path (for Windows, for example, C:\Windows\System32) can skip the latter task, but it can affect other applications, so I think it's safe to stop.)
Therefore, the direction to solve the problem is to automate (hide) the recipient so that they do not explicitly do the above.
As a classic solution, I can think of creating my own installer for this program.
This way, the installer will deploy and configure the files, so the recipient of the program will not have to worry about things like jri.dll.
The next possible solution is to include jri.dll in the jar file and deploy it from jar to the file system at runtime.
There are some predecessors in this regard, and the following link may be helpful:
It's not that difficult to implement it yourself because you just deploy jri.dll in jar, and I think the solution in this direction is the most realistic.
The third solution is to provide the virtualized environment itself with a pre-built running environment.
As we provide a complete set, the receiver does not need to consider not only JRI but also R and Java.
However, instead of having to consider JRI, recipients will need to know more about the virtual environment, so this may be an overkill.
For your information, I was a little interested in the running environment last time, so I will show you the Dockerfile I made at that time:
If you have any answers or tips
© 2024 OneMinuteCode. All rights reserved.