Быстрый (с точки зрения затрат времени разработчика) способ использования большого количества кода C++ из Java.

При любом выборе вам нужно будет сделать некоторую упаковку. Хотя вы не хотите писать оболочки JNI для каждого класса, вы можете написать классы C++ более высокого уровня, которые охватывают группы методов. Затем вам нужно написать обертки только для классов более высокого уровня (этот подход работает и для других методов, а не только для JNI).

Напишите небольшое приложение на C++, которое считывает ввод со стандартного ввода и записывает вывод на стандартный вывод. Затем запустите процесс из своего Java-приложения и прочитайте вывод из стандартного вывода.

Это лучший способ сделать это без JNI (и это довольно легко сделать)

Я бы порекомендовал инструмент для создания интерфейса Dropbox djinni. Они используют его для своих кроссплатформенных мобильных приложений для создания интерфейсов между интерфейсом Java (Android) и Objective-C (iOS) и своей моделью данных C++.

Facebook тоже использовал его для одного из своих приложений. Так что я бы предположил, что это довольно хорошо проверено.

Посмотрите их выступление на CppCon, чтобы узнать, чем они занимаются. Взаимодействие между Java и C++ с использованием JNI кажется особенно подверженным ошибкам.

JNIEasy поддерживает отображение Классы C++ в классы Java POJO, но это стоит 399€. Поскольку вы предпочитаете бесплатные библиотеки, возможно, вы захотите поискать решения, использующие что-то вроде CORBA. Это единственный способ сопоставить классы C++ с классами Java.

РЕДАКТИРОВАТЬ: Рассматривали ли вы JAS3, это библиотека Java, похожая на root?

Просто мысль, но можете ли вы использовать Python, поскольку Root уже поддерживает его? Вы вполне могли бы стать достаточно опытными за то время, которое потребовалось бы для обертывания кода для Java.

Рассмотрите возможность использования C# вместо Java. Если вы уже знакомы с Java, перейти на C# несложно, и в нем многое улучшенная поддержка для вызова нативного кода.

Как насчет написания классов/функций, которые вам нужны, на C++, компиляции и вызова exec() для них из java?

Всякий раз, когда вы вызываете код C или C++ из Java через JNI или эквивалент, вы рискуете дестабилизировать платформу Java из-за проблем с управлением памятью и/или безопасностью потоков на стороне C/C++.

Прежде чем идти по маршруту JNI и т. Д., Я думаю, вам следует рассмотреть другие альтернативы:

• Уберите Java из уравнения и полностью реализуйте на C++ (или C++/CC#, как предложил кто-то другой).
• Создайте приложение командной строки C++, которое выполняет задачу, которую вам нужно выполнить, используя собственную библиотеку, и запустите приложение, используя один из методов java.lang.Runtime.exec.
• Создайте «серверную» оболочку на C++ для библиотеки, которая предоставляет необходимые вам функции в виде пользовательского протокола, и закодируйте сторону Java для взаимодействия с сервером с использованием HTTP, необработанных сокетов, каналов или любого другого подходящего уровня транспорта.

Все альтернативы имеют недостатки, но JNI/JNA и им подобные тоже; см. первый абзац.

РЕДАКТИРОВАТЬ: когда вы принимаете решение использовать JNI/JNA в системе, вероятны долгосрочные последствия. В дополнение к проблеме со стабильностью вы должны учитывать переносимость (будет ли нативная библиотека работать в Windows, Linux и т. д.), проблемы со сборкой (сложно создавать нативные библиотеки в Ant и т. д.), проблемы с версиями платформы (будет ли обновление до Java 7 что-то сломать?), навыки разработчика ("ушел Джо", который занимался интеграцией JNI - кто еще знает Java, C++ и JNI?). Сумма этих проблем (IMO) более значительна, чем время, необходимое для первоначальной разработки.

если будет сложно, скорее всего будем использовать Qt

Почему бы вам не сосредоточиться на этом? До сих пор вы не упомянули ни одной причины, по которой следует предпочесть Java.

Если самой большой частью является исходный код ROOT и код, который его вызывает, вы, вероятно, будете намного быстрее делать все это на C++.
Поскольку вы хорошо работаете с Qt, пользовательский интерфейс не должен много о чем беспокоиться.

изменить:
Я не вижу никаких преимуществ в Java-подходе - вам все равно придется портировать большую часть исходного кода на другие платформы, вы добавляете сложности с помощью слоя упаковки и у вас больше зависимостей.