R de java sans graphique: vaut-il la peine de passer à JRI

Question

J'ai un système configuré qui fonctionne avec bonheur R à partir d'une servlet java, engendrant le traitement de & dans les flux stdin, stdout et stderr du processus, comme dans le deuxième andwer à this question.

Après une mise à niveau du système (qui inclus glibc), l'entrée n'atteint plus le processus de R *.

Jusqu'à présent, R --vanilla --slave -f [fichier] ... 'était fonctionne bien pour moi. Je n'ai pas non plus de dépendances swing pour le moment, donc je suis un peu réticent à les ajouter. (Je ne peux pas être capable pour ajouter des dépendances de swing, ai-je raison que l'utilisation de REngine apporte automatiquement swing? Les exemples importent tout swing.)

Y at-il des avantages à passer à JRI? Quels changements dois-je apporter à mon script R? (Il lit actuellement depuis stdin et écrit sur stdout). Je ne trouve pas les exemples fournis terriblement utiles pour savoir comment utiliser JRI dans cette situation.

Merci pour votre aide & commentaires.

* Je ne peux même pas dire si le problème est que les données sont écrites trop tôt ou trop tard, mais c'est une question/question distincte; Si je passe à JRI, j'espère que tout deviendra inutile.

Answer 1

Mes deux cents:

Je trouve que travailler avec JRI pour être simple. Il y a plusieurs exemples fournis avec JRI qui donnent une bonne démonstration de la façon de l'utiliser.

En général, vous ne devriez pas avoir à apporter de modifications majeures à votre script, car vous pouvez simplement transmettre un script entier en tant qu'expression avec la fonction eval(), puis gérer la valeur de retour. Le principal avantage que je vois est que vous manipulez ensuite le processus R à partir de votre code Java, de sorte que vous pouvez le faire avec des exceptions correctement sans avoir à passer d'appels système. JRI fournit également quelques équivalents de type de données R dans Java tels que RVector.