R из Java без графики: стоит ли переходить на JRI

Question

У меня есть настроенная система, которая успешно запускает R из сервлета java, порождает обработанные и подключается к потокам stdin, stdout и stderr, как во втором andwer к этому вопросу .

После обновления системы (включая glibc) ввод больше не достигает процесса R. *

До сих пор 'R --vanilla --slave -f [файл] ...' работал нормально для меня. У меня также нет свинг-зависимостей прямо сейчас, поэтому я неохотно их добавляю. (На самом деле я не могу иметь возможность добавлять зависимости свинга; правильно ли я, что использование REngine автоматически приводит к свингу? Примеры импортируют все свинг.)

Есть ли преимущества при переходе на JRI? Какие изменения мне нужно внести в мой R-скрипт? (В настоящее время он читает из стандартного ввода и пишет в стандартный вывод). Я не нахожу приведенные примеры очень полезными для использования JRI в этой ситуации.

Спасибо за вашу помощь и комментарии.

* Я даже не могу сказать, является ли проблема записью данных слишком рано или слишком поздно, но это отдельная проблема / вопрос; если я перейду в JRI, я надеюсь, что все станет спорным.

Answer 1

Мои два цента:

Я считаю, что работать с JRI просто. JRI предоставляет несколько примеров, которые хорошо демонстрируют, как его использовать.

В общем случае вам не нужно вносить каких-либо серьезных изменений в ваш скрипт, потому что вы можете просто передать весь скрипт как выражение с помощью функции eval() и затем обработать возвращаемое значение. Основное преимущество, как я вижу, состоит в том, что вы затем обрабатываете процесс R из своего Java-кода, так что вы можете делать исключения правильно, не делая никаких системных вызовов. JRI также предоставляет некоторые эквиваленты типов данных R в Java, такие как RVector.