Comments 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 такое не сделаешь. Вот тут, да, нативный код очень помог.
UFO just landed and posted this here
Преимущество нативного кода это не только время его исполнения, но и доступ к ресурсам, которые для 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++…
UFO just landed and posted this here
В свое время хапнул горя с JNI. Был враппер к внешней либе. Проблемы были с управлением памятью. Для сборщика мусора нативные объекты не существуют. Он вполне может грохнуть java-объект, который держит указатель на нативный, хотя нативный еще используется. В итоге падает вся ява-машина, вместе с аппликейшн-сервером и всей инфраструктурой.
Упасть может и через трое суток работы под нагрузкой. Ловили причину долго. Поправили.
В итоге для уверенности реализовали нативный компонент целиком на яве.
Упасть может и через трое суток работы под нагрузкой. Ловили причину долго. Поправили.
В итоге для уверенности реализовали нативный компонент целиком на яве.
Похоже, что вы просто не осилили документацию.
То, что сборщик грохает Java-объект это нормально. Если вас беспокоит освобождение памяти, для удаление нативного объекта воспользутесь finalize или сделайте lifecycle Java-объекта явным. Если нужно, чтоб нативный объект ссылался на Java-объект, просто нужно создать reference через NewGlobalRef.
И все.
То, что сборщик грохает Java-объект это нормально. Если вас беспокоит освобождение памяти, для удаление нативного объекта воспользутесь finalize или сделайте lifecycle Java-объекта явным. Если нужно, чтоб нативный объект ссылался на Java-объект, просто нужно создать reference через NewGlobalRef.
И все.
Sign up to leave a comment.
Java Native Interface. C++. Linux. Первые шаги