Комментарии 23
Попробуйте JNA, немного медленне, но гораздо удобнее. Самое главное что нет всех ужасных
JNIEXPORT jint JNICALL Java_by_framework_nativeapp_NativeCode_getInt
Если использовать class-specific макросы, то подобные конструкции можно писать всего один раз, потом просто пользоваться готовыми дефайнами.
Можно. Но не понятно зачем.
Кроме того, что с преобразованиями типов? JNA делает их автоматически (String <-> char* например)
Кроме того, что с преобразованиями типов? JNA делает их автоматически (String <-> char* например)
спешу вас огорчить, у std::string просто напросто перегружен оператор присваивания
string& operator= ( const char* s );
string& operator= ( const char* s );
Речь идет о Явовском стринге
stackoverflow.com/questions/9180351/jni-convert-string-to-char-array
stackoverflow.com/questions/9180351/jni-convert-string-to-char-array
Смотрел, выглядит интереснее и проще. Определимся, когда будем видеть сколько вызовов C++ функций у нас будет. Две или три скорее всего нигде погоды не сделают.
JNA очень ограниченно работает с С++: Java Native Access doesn't do C++, right?
Если нужно работать с именно объектным апи, придется писать обертку на С, или использовять BridJ. Он умеет мапить классы и прочие плюшки.
Если нужно работать с именно объектным апи, придется писать обертку на С, или использовять BridJ. Он умеет мапить классы и прочие плюшки.
Для JNI (и не только) удобно использовать SWIG.
А не. Поддерживает
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
а если дальше прочитать?
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.
SWIG упрощает задачу, но как бы список requirements для сборки у нас не стал больше кода самого приложения. Нужно оценивать масштаб при выборе инструментов.
разницы в jni для *nix и windows практически никакой нет. единственное на что надо обратить внимание это x86 и x86_64
Header получаем утилитой javah из скомпилированного class-файла.
Помню первую сборку native библиотеки под Android NDK — с первого раза и не понять, как формируются имена функций.
Помню первую сборку native библиотеки под Android NDK — с первого раза и не понять, как формируются имена функций.
Думал правда будете писать код, считающий котят. В таком случае было бы действительно интересно посмотреть «А стоит ли овчинка выделки?». Не покроет ли все преимущество нативного кода оверхед от JNI?
Все зависит от задачи. Когда-то у меня была задача попросить Windows через UAC повышение привилегий моему процессу. Напрямую из Java такое не сделаешь. Вот тут, да, нативный код очень помог.
НЛО прилетело и опубликовало эту надпись здесь
Преимущество нативного кода это не только время его исполнения, но и доступ к ресурсам, которые для Java не доступны. Во втором случае с оверхедом придётся смириться.
Около года 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.
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.
Да кстати, Кристи на сайте имеют картинку, вот она: 
я не уверен какая это версия, все таки я для них это делал уже 8 лет тому, но это то что Java + JNI + C++ и драйвера делают. На мониторах внизу, перед девочкой это система, которая через Java HTTP / JSP сервер видео в браузер передает, на видео стене вверху это главная программа управления видео стенами, Java, JNI, C++…
я не уверен какая это версия, все таки я для них это делал уже 8 лет тому, но это то что Java + JNI + C++ и драйвера делают. На мониторах внизу, перед девочкой это система, которая через Java HTTP / JSP сервер видео в браузер передает, на видео стене вверху это главная программа управления видео стенами, Java, JNI, C++…
НЛО прилетело и опубликовало эту надпись здесь
В свое время хапнул горя с JNI. Был враппер к внешней либе. Проблемы были с управлением памятью. Для сборщика мусора нативные объекты не существуют. Он вполне может грохнуть java-объект, который держит указатель на нативный, хотя нативный еще используется. В итоге падает вся ява-машина, вместе с аппликейшн-сервером и всей инфраструктурой.
Упасть может и через трое суток работы под нагрузкой. Ловили причину долго. Поправили.
В итоге для уверенности реализовали нативный компонент целиком на яве.
Упасть может и через трое суток работы под нагрузкой. Ловили причину долго. Поправили.
В итоге для уверенности реализовали нативный компонент целиком на яве.
Похоже, что вы просто не осилили документацию.
То, что сборщик грохает Java-объект это нормально. Если вас беспокоит освобождение памяти, для удаление нативного объекта воспользутесь finalize или сделайте lifecycle Java-объекта явным. Если нужно, чтоб нативный объект ссылался на Java-объект, просто нужно создать reference через NewGlobalRef.
И все.
То, что сборщик грохает Java-объект это нормально. Если вас беспокоит освобождение памяти, для удаление нативного объекта воспользутесь finalize или сделайте lifecycle Java-объекта явным. Если нужно, чтоб нативный объект ссылался на Java-объект, просто нужно создать reference через NewGlobalRef.
И все.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java Native Interface. C++. Linux. Первые шаги