Подход с использованием модели через JNI/JNA увеличивает стоимость поддержки (насколько конкретно — в каждом отдельном случае необходимо считать), т.к. необходимо делать сборку и в последующем поддерживать под каждую архитектуру. Если все на одной архитектуре, такой проблемы нет — один раз собрал и протестировал.
Кстати говоря, фрэймворк DL4J не на чистом Java. Имеет декомпилированные классы на C++ и под капотом у него используется как раз JNI.
Как вариант. Если создается сервис у которого всего один прод, то можно и сервис с Flask развернуть, можно и вызвать удаленно Python-скрипт, предварительно установив окружение. Микросервисы хороши в проектных решениях. В продуктовых, где предлагается коробочное решение с высокой тиражируемостью это не лучшее решение с точки зрения архитектуры, поддержки, развертывания.
Проблема не в вызове, а в том что для Python нужно подтягивать свое окружение под каждую платформу. На практике этот вариант имеет место быть. Тут уже вопрос больше не технический, а финансовый.
Тикеты не оставлял. Только общался на gitter с разработчиками. Вопросов было много, ответы поступают не сразу, поэтому к вопросам приходилось относится очень избирательно.
Статья получилась действительно емкой вследствие того что материала по этому вопросу много.
Не исключаю, что этого могло отразиться на наглядном и информативном представлении.
Статья, несомненно, будет полезна для прочтения для тех, кому потребуется решать задачу исправления опечаток.
Кстати говоря, фрэймворк DL4J не на чистом Java. Имеет декомпилированные классы на C++ и под капотом у него используется как раз JNI.
Не исключаю, что этого могло отразиться на наглядном и информативном представлении.
Статья, несомненно, будет полезна для прочтения для тех, кому потребуется решать задачу исправления опечаток.