R from java with no graphics: is it worth moving to JRI

Question

I have a system set up that's been happily running R from a java servlet, spawning processed & hooking into the process's stdin, stdout, and stderr streams, as in the second andwer to this question.

After a system upgrade (that included glibc), the input is no longer reaching the R process.*

Until now, 'R --vanilla --slave -f [file] ...' was working fine for me. I also have no swing dependencies right now, so I'm somewhat reluctant to add them. (I may actually not be able to add swing dependencies; am I right that using REngine automatically brings swing in? The examples import all of swing.)

Are there advantages to switching to JRI? What changes would I need to make to my R script? (It currently reads from stdin and writes to stdout). I'm not finding the provided examples terribly helpful for how to use JRI in this situation.

Thanks for your help & comments.

*I can't even tell if the problem is data being written too soon or too late, but that's a separate issue/question; if I move to JRI I'm hoping it all becomes moot.

Answer 1

My two cents:

I find working with JRI to be straight-forward. There are several examples provided with JRI that give a good demonstration of how to use it.

In general, you shouldn't have to make any major changes to your script because you can simply pass in an entire script as an expression with the eval() function and then handle the return value. The main advantage as I see it is that you're then handling the R process from within your Java code, so you can with exceptions properly without having to make any system calls. JRI also provides some R data type equivalents in Java such as RVector.