Java Native Interface. C++. Linux. Первые шаги

[javax]

Попробуйте JNA, немного медленне, но гораздо удобнее. Самое главное что нет всех ужасных JNIEXPORT jint JNICALL Java_by_framework_nativeapp_NativeCode_getInt

[crmMaster]

Если использовать class-specific макросы, то подобные конструкции можно писать всего один раз, потом просто пользоваться готовыми дефайнами.

[javax]

Можно. Но не понятно зачем.

Кроме того, что с преобразованиями типов? JNA делает их автоматически (String <-> char* например)

[denim]

спешу вас огорчить, у std::string просто напросто перегружен оператор присваивания
string& operator= ( const char* s );

[javax]

Речь идет о Явовском стринге
stackoverflow.com/questions/9180351/jni-convert-string-to-char-array

[Framework]

Смотрел, выглядит интереснее и проще. Определимся, когда будем видеть сколько вызовов C++ функций у нас будет. Две или три скорее всего нигде погоды не сделают.

[tulskiy]

JNA очень ограниченно работает с С++: Java Native Access doesn't do C++, right?

Если нужно работать с именно объектным апи, придется писать обертку на С, или использовять BridJ. Он умеет мапить классы и прочие плюшки.

[dea]

Для JNI (и не только) удобно использовать SWIG.

[crmMaster]

Я так понял Java из коробки не поддерживает

А не. Поддерживает

SWIG currently generates wrapper code for nineteen different target languages:
Allegro CL
C#
CFFI
CLISP
Chicken
D
Go
Guile
Java
Lua
Modula-3
Mzscheme
OCAML
Octave
Perl
PHP
Python
R
Ruby
Tcl
UFFI

[dea]

а если дальше прочитать?

The list of supported languages also includes non-scripting languages such as C#, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), D, Go language, Java including Android, Lua, Modula-3, OCAML, Octave and R.

[Framework]

SWIG упрощает задачу, но как бы список requirements для сборки у нас не стал больше кода самого приложения. Нужно оценивать масштаб при выборе инструментов.

[denim]

разницы в jni для *nix и windows практически никакой нет. единственное на что надо обратить внимание это x86 и x86_64

[antonyter]

Header получаем утилитой javah из скомпилированного class-файла.

Помню первую сборку native библиотеки под Android NDK — с первого раза и не понять, как формируются имена функций.

[spiff]

Думал правда будете писать код, считающий котят. В таком случае было бы действительно интересно посмотреть «А стоит ли овчинка выделки?». Не покроет ли все преимущество нативного кода оверхед от JNI?

[VorteKC]

Все зависит от задачи. Когда-то у меня была задача попросить Windows через UAC повышение привилегий моему процессу. Напрямую из Java такое не сделаешь. Вот тут, да, нативный код очень помог.

[Framework]

Преимущество нативного кода это не только время его исполнения, но и доступ к ресурсам, которые для Java не доступны. Во втором случае с оверхедом придётся смириться.

[romanmir]

Ошибся веткой, извиняюсь.

[romanmir]

Около года 2004го у меня был контракт с Christie Digital, я для них написал несколько систем, две из них заключались в следующем:

1. Java GUI, со своей базой данных, которое позволяет одновременно или по очереди показывать любое количество видео каналов с различными спец-эффектами (картинка в картинке, текст сверху добавляли, искажали картинку для того, чтобы компенсировать искажение экрана, если например экран выгнутый или имеет углы, запись, воспроизведение, и т.д.) Железо Christie Digital клепали сами, строили проектора, разных видов огромные 70"+ 'телевизоры', которые можно составлять в видео стены. Но различные видео компоненты приходили от других производителей, видео карты самых разных типов, capture устройства, и к ним были свои драйвера. Так вот, я оборачивал драйвер сверху более высоким типом драйвера, которые мы сами писали, а потом использовал JNI для того, чтобы в Java GUI можно было показывать видео выход. Правда Java не много делала, оформляла окна, управляла окнами, сохраняла настройки и т.п. Видео на экран выводила C++ обертка, которая управляла драйвером, а Java уже коммандовала C++ оберткой, говорила ей куда что и как идет. Все работало быстро. Для чего Java там была? Они хотели иметь одинаковый интерфейс на всех платформах, я для них сделал необычные окна на Java, не просто квдратики как JFrame обычно выглядит, а свои графические темы, оформления.

2. Java сервер, делал опять же video capture и отправлял stream в браузер для удаленного управления видео окнами, расположением окон и пр.

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

[romanmir]

Да кстати, Кристи на сайте имеют картинку, вот она:

я не уверен какая это версия, все таки я для них это делал уже 8 лет тому, но это то что Java + JNI + C++ и драйвера делают. На мониторах внизу, перед девочкой это система, которая через Java HTTP / JSP сервер видео в браузер передает, на видео стене вверху это главная программа управления видео стенами, Java, JNI, C++…

[alex_shabalin]

В свое время хапнул горя с JNI. Был враппер к внешней либе. Проблемы были с управлением памятью. Для сборщика мусора нативные объекты не существуют. Он вполне может грохнуть java-объект, который держит указатель на нативный, хотя нативный еще используется. В итоге падает вся ява-машина, вместе с аппликейшн-сервером и всей инфраструктурой.
Упасть может и через трое суток работы под нагрузкой. Ловили причину долго. Поправили.
В итоге для уверенности реализовали нативный компонент целиком на яве.

[Ganga]

Похоже, что вы просто не осилили документацию.

То, что сборщик грохает Java-объект это нормально. Если вас беспокоит освобождение памяти, для удаление нативного объекта воспользутесь finalize или сделайте lifecycle Java-объекта явным. Если нужно, чтоб нативный объект ссылался на Java-объект, просто нужно создать reference через NewGlobalRef.

И все.