I have a Java app which needs to perform partial least squares regression. It would appear there are no Java implementations of PLSR out there. Weka might have had something like it at some point, but it is no longer in the API. On the other hand, I have found a good R implementation, which has an added bonus to it. It was used by the people whose result I want to replicate, which means there is less chance that things will go wrong because of differences in the way PLSR is implemented.
The question is: is there a good enough (and simple to use) package that enable Java to call R, pass in some parameters to a function and read back the results? My other option is to have Java spawn R in a Process and then monitor it. Data would be read and written to disk. Which of the two would you recommend? Am I missing the obvious third option?
I have successfully used two alternatives in the past.
JRI
Pros: probably better performance.
Cons: you have to configure some environment variables and libraries, different in Win/UNIX.
RServe
Pros: easy to setup, you don't need to initialize R or link against
any R library, can run in a different machine.
Cons: based on TCP/IP (a server is running), no callbacks from R.
Other alternatives I have never used : RCaller
There has been work by Duncan Temple Lang: http://rss.acs.unt.edu/Rdoc/library/SJava/Docs/RFromJava.pdf .
My guess as to the most robust solution would be JGR. The developers of JGR have a mailing list, Stats-Rosuda and the mailing list Archive indicates the list remains active as of 2013.
There is also code that has been put up at Googlecode, with an example here:
http://stdioe.blogspot.com/2011/07/rcaller-20-calling-r-from-java.html
This is an old question.. but for anyone browsing through here that is still interested: I wrote a blog article that provides a detailed example of how to use JRI/rjava (a JNI based bridge) to do this type of thing (the how-to is focused on Linux dev environments). I also compare and contrast alternative approaches for doing 'mathy' stuff by calling out to R and similar frameworks.
URL > http://buildlackey.com/integrating-r-and-java-with-jrirjava-a-jni-based-bridge/
Renjin is an alternative that allows not only the integration of many packages of R also a easy going communication between Java and R through objects:
http://www.renjin.org/
JRI has both low level and High level interface to Call R from Java. There is an eclipse plugin that helps in setting up the R Java environment at http://www.studytrails.com/RJava-Eclipse-Plugin/.
This seems to be an old question. However Rserve and rJava are two good packages to integrate R with Java. Following blogs explain usage of both these libraries.
For rJava: http://www.codophile.com/how-to-integrate-r-with-java-using-rjava/
For Rserve: http://www.codophile.com/how-to-integrate-r-with-java-using-rserve/
I hope this will help.
I had similar need a while back and tested a few of the interfaces to R. The one I found to be the best for my needs (windows, c#) was Rserve which I believe is written in Java. My only gripe with it is that it wasn't 64-bit. I used a simple client written in c# and it worked very well. I'm sure the Java client is a lot better.
FastR is a GraalVM based implementation of R. Embedding it in a JVM application is as simple as:
Context ctx = Context.newBuilder("R").allowAllAccess(true).build();
ctx.eval("R", "sum").execute(new int[] {1,2,3});
More details in this article: https://medium.com/graalvm/faster-r-with-fastr-4b8db0e0dceb
Related
I've got a big problem with IBM HACL for accessing a server which speaks 3270 protocol. The library keeps crashing, and our JNI wrapper is actually a bug-fixing layer for the poorly-implemented and poorly-documented library (and I suspect we have introduced new bugs with it too). Moreover, in our company, everybody knows Java, and could maintain the software if we didn't have the JNI-Layer and the IBM class library.
We have to use the C++ class library, because the IBM Java library is unusable: we get every non-printable character translated, and we lose all control characters along the way.
Now the question is: can we ditch this library and implement our solution in Java completely (we'd like to avoid using another library from another vendor)? Is the protocol well documented? Is the implementation of 3270-over-ssl really so complex?
Thanks.
https://www.rfc-editor.org/rfc/rfc1041
so i guess its documented (assuming i hit the right doc)
couldnt find a java implementation though, you'd need to code it over telnet, or maybe SSH
I am unfamiliar with the differences between 3270 and 5250 data streams, but there is a 5250 implementation in Java in the tn5250j project available from http://tn5250j.sourceforge.net/
It might be usable for you?
(also there is a 3270 screen scraping project at http://freehost3270.sourceforge.net/ but it appears to be abandoned).
freehost3270 doesn't look as abandoned as it might appear - CVS has changes from 2 years ago. There is always an arguement that good code won't need to be changed that often in any case if the requirements have not altered. There have been complimentary comments wrt to the codebase. If you don't particularly want to work with other vendors products then working with this code/project seems to be your best option.
Freehost is not good code. Do not even bother trying it. There is a reason that it seems dead. JIN TN3270 is better but is incomplete. Ideally you want to find the API that your company's Emulator software uses. I am still searching for one for ours.
Another option would be h3270. It is a Java front-end to the x3270 suite of tools.
Is rjava the only way to connect R to Java? I am asking because there is a disclaimer at the end of the web page:
This interface uses Java reflection
API to find the correct method so it
is much slower and may not be right
(works for simple examples but may not
for more complex ones). For now its
use is discouraged in programs as it
may change in the future.
This is slightly concerning. How do you address this issue? I know that Rweka has a self-contained interface, so I may look into that package, but maybe many R users have already gone through the pains.
It is not the only one as the Omegahat project also has the RSJava package. But as many of the other brilliant innovations from Omegahat (which practically speaking is really just Duncan Temple Lang), this one may not build as easily or reliably.
The rJava package on the other hand is used by almost thirty other packages
CADStat, Containers, Deducer, JGR,
RFreak, RImageJ, RJDBC, RLadyBug,
aCGH.Spline, ant, arulesNBMiner,
colbycol, cshapes, dynGraph, farmR,
gWidgetsrJava, glmulti,
helloJavaWorld, iplots, rSymPy, rcdk,
rcdklibs, scagnostics, spcosa, RKEA,
RWeka, Snowball, openNLP, wordnet
which I take as quite the endorsement.
I think that disclaimer only applies if you use the $ operator to access your java objects. As long as you stick with the .jcall function you won't incur the overhead.
In terms of experience using rJava, I've found it works exactly as advertised and for my package (farmR) it hasn't caused any performance problems. I don't make a huge number of calls into java though, and I haven't used any of the java GUI toolkits.
I am an Rweka user, and I can tell you it is amazingly quick, it outperforms weka alone, while using it's functions in the r environment. I think that the R package has a very special way to integrate inside the language java libraries, nevertheless these libraries need to be prepared to allow this. For being able to do a proper integration you will need to do an important amount of research in order to see how to make things fit properly. I recommend you to read the documentation that comes with R, which details which are the best practices for writing NEW LIBRARIES libraries.
I am considering using GraphicsMagick (http://www.graphicsmagick.org/) in a Java project. Does anyone have any experience with this? Suggestions on how to get started? It seems like there isn't a native Java library so it may be a little more difficult.
Thanks!
We did our project with GraphicsMagick and Java, Q&A here obvious influence our decision. It's a long way but we eventually got it done. We tweaked both GraphicsMagick and im4java very hard to get the performance and reliability we want. Thought I should contribute back:
http://kennethxu.blogspot.com/2013/04/integrate-java-and-graphicsmagick.html
It's definitely possible. Take a look at IM4Java, a Java abstraction around the commandline interfaces of various ImageMagick like tools (including GM) that feels like a language binding. Very little documentation, but sufficiently simple. Obviously your images have to be accessible from the OS (e.g. not inside ResourceBundles).
Currently the only reasonable way to achieve this is by using the command line from Java (runtime.exec). You should use im4java to do this as suggested above. im4java will enable you to build up your "gm command" string using java method calls, it also provides a number of other useful features.
The big advantage of using this technique over actual language bindings is simplicity and reliability. Reliability is important especially if your Java app is running on a Java based server or servlet engine like tomcat. The reason being that a memory fault or other error while using language bindings could bring down the whole Java virtual machine.
I've got a medium sized (25k lines code, 25k lines tests) codebase in java, and would like to port it to run on a CLR as well as the JVM.
Only the main class, and a few testing utilities deal with the file system or OS in any way. The rest of the code uses the generic collections APIs extensively, java.util.regex, java.net (but not URL or URLConnection), java.io for charset encoding/decoding, java.text for unicode normalization, and org.w3c.dom for XML manipulation.
Is it possible to get most of the codebase compiling under both J# and Java, and then port the rest?
If so, what kind of pitfalls am I likely to run into?
thanks in advance,
mike
Check out IKVM: http://www.ikvm.net/
It allows you to run (specially compiled) Java code inside the .Net CLR.
Some of my colleages have used it successfully with a Java codebase of 1 million+ lines of code.
Pitfalls:
Anything like this scares the heck out of me. The number of really subtle bugs waiting to happen is huge.
J# only supports Java 1.1.4 AFAIK - goodbye generics etc.
Visual Studio 2008 doesn't support J# - basically it's a dead project.
I suspect that you'd actually find it simpler to rewrite it in C# (including learning C# if you don't already know it - it's a joy). You'll end up with a more idiomatically .NET-like library that way as well, if that's relevant: if you ever want another .NET developer to consume your code, they're likely to be far happier with a "pure" .NET project than one using J#.
The downside is that going forward, any changes would also need to be made in two places. There's certainly pain there, but I really think you'll have a better experience using "normal" .NET.
As Jon pointed out: J# is pretty dead.
Running your (normal) Java code on .NET using IKVM might be an alternative, 'though.
I was curious if anyone had any suggestions on a Java library that provides access to MSMQ? I've downloaded the trial of the J-Integra Java-COM library and have built and run their MSMQ example app, but I was curious if there were any good (free :)) alternatives. I've run across a few JNI implementations like jMSMQ and a few others, but I'd rather avoid JNI if possible.
We've also investigated some .NET<->JMS interop solutions like JNBridge (with ActiveMQ). I think our company has decided to centralize our queueing in MSMQ however, so that would be our ideal solution.
We are hoping to use WCF (netMsmq or msmqIntegration) on the .NET side. I'm a little concerned about how the java side will deal with the WCF messages (binary encoding), but there should be options there (customBinding with text encoding and MSMQ transport?), so I'm not too worried about that. Mostly worried about getting access to MSMQ in Java.
Our other option is to just put a thin web-service layer at the input end of each queue, and achieve interop that way. Performance is a little bit of a concern there, however.
Any suggestions? Thanks a lot for anyone's time.
As far as I understand J-Integra is the only pure Java implementation of MSMQ, ie this is the only alternative if you are not running on Windows. (Please let me know if there are other alternatives!)
Apache Camel and other uses JNI to access the Windows API (DLL files) which obviously means that is only works on Windows.
I am currently trying out the code provided here http://www.codeplex.com/MsmqJava which seems simple to use, but I'm not really sure how transactions work.
There is an open-source library on CodePlex: MsmqJava. Free.
You can also try the http://javamsmq.codeplex.com/ which is also provide a complete solution of MSMQ JAVA interoperability.As well this having Unicode ASCII all functionality.In other dll based open source having memory leakage problem like crashing of application.But this open source don't having any memory leakage problem.
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
Update: This answer no longer applies per comment:
Camel msmq component is discontinued :
fusesource.com/forums/thread.jspa?messageID=6040
You might take a look at how Apache Camel does it: Apache Camel: msmq