Comments 24
Нет никаких проблем с JNI если ты знаешь Java и C. Да надо генерить header файл, а потом его реализовывать.
Но если вы присмотритесь, в генерируемых названиях функций нет ничего потустороннего. Все четко и ясно, предсказуемо настолько что после 2й функции можно самому его ручками дописывать.
Но если вы присмотритесь, в генерируемых названиях функций нет ничего потустороннего. Все четко и ясно, предсказуемо настолько что после 2й функции можно самому его ручками дописывать.
Согласен, всё ясно, но согласитесь что читаемости кода эти сигнатуры не способствуют.
Я, как программист, должен заниматься бизнес логикой, а не boilerplate code — преобразованием типов и т.д.
Я, как программист, должен заниматься бизнес логикой, а не boilerplate code — преобразованием типов и т.д.
Кстати, могут мне знатоки явы обьяснить, почему javah формирует функции вида Java_Package_Class_method, и тогда у меня вылетает UnsatisfyedLinkException, но если исправить на _Java_Package_Class_method, все работает отлично?
версия 1.6.0_23
версия 1.6.0_23
По большому счёт действительно так, но есть и небольшие заморочки:
1. jni в некоторых случаях оказывается пошустрее (одна из первых ссылок в гугле stackoverflow.com/questions/1556421/use-jni-instead-of-jna-to-call-native-code)
2. нюансы с лицензиями (для примера из того же хадуп стека, что и касандра issues.apache.org/jira/browse/HADOOP-6767)
в общем всё зависит от того как и где использовать, для внутреннего потребления сойдут обе, а вот если проект открытый и дописываешь функционал, то сразу нужно уточнить в каком виде примут твой патч.
1. jni в некоторых случаях оказывается пошустрее (одна из первых ссылок в гугле stackoverflow.com/questions/1556421/use-jni-instead-of-jna-to-call-native-code)
2. нюансы с лицензиями (для примера из того же хадуп стека, что и касандра issues.apache.org/jira/browse/HADOOP-6767)
в общем всё зависит от того как и где использовать, для внутреннего потребления сойдут обе, а вот если проект открытый и дописываешь функционал, то сразу нужно уточнить в каком виде примут твой патч.
Спасибо! Это полезно.
А проблемы с лицензиями я не очень понял. Ведь LGPL мне не мешает если JNA у меня как отдельный jar, правильно?
А проблемы с лицензиями я не очень понял. Ведь LGPL мне не мешает если JNA у меня как отдельный jar, правильно?
основное обсуждение www.mail-archive.com/legal-discuss@apache.org/msg00009.html и www.gnu.org/licenses/lgpl-java.html
Одно из основных отличий GPL и LGPL в том, что первая запрещает линковать модули под ней в закрытые приложениях, а LGPL позволяет это делать (на этом и выеждают многие разработчики: пижут закрытый софт, пижут LGPL библиотеку A которая в свою очередь дёргает популярную GPL библиотеку B, в итоге можно смело открывать A, так как она ничего не содержит полезного, но в тоже время позволяет осталять сам продукт закрытым).
но со стороны явы мы имеем «public interface MyLib extends Library», то есть уже идёт расширение/модификация кода и продукт по идее тоже должен быть уже под LGPL.
Вот из-за этого нюанса и висит вопрос, так как объяснений я пока ещё не встречал как его интерпретировать
Одно из основных отличий GPL и LGPL в том, что первая запрещает линковать модули под ней в закрытые приложениях, а LGPL позволяет это делать (на этом и выеждают многие разработчики: пижут закрытый софт, пижут LGPL библиотеку A которая в свою очередь дёргает популярную GPL библиотеку B, в итоге можно смело открывать A, так как она ничего не содержит полезного, но в тоже время позволяет осталять сам продукт закрытым).
но со стороны явы мы имеем «public interface MyLib extends Library», то есть уже идёт расширение/модификация кода и продукт по идее тоже должен быть уже под LGPL.
Вот из-за этого нюанса и висит вопрос, так как объяснений я пока ещё не встречал как его интерпретировать
Погодите, где же тут модификация кода? Я же не модифицирую код Library, я его использую! Насколько я знаю если динамически линковаться с LGPL библиотекой (а Ява только динамическое линкование и поддерживает), то никаких проблем нет.
да, по поводу явы немного ошибся, уточняя вопрос по второй ссылке объяснение от самих gnu.
FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.
а у большинства продуктов в eula явно прописано, что реверсинженеринг запрещён.
FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.
а у большинства продуктов в eula явно прописано, что реверсинженеринг запрещён.
Как-то приходилось писать прокси с С++ либы. Я вам скажу затея не для слабонервных. Доки приходилось выкапывать с таким трудом. Иногда тупо кроме брутфорса понять не реально что и как. В простых случаях это лаконично выглядит. В реальных приложения ловить сикфолты и недокументированные эксепшены весьма достает.
Для интеграции с C++ есть SWIG
Спасибо, гляну. Сходу не понял, что же проще?!
Если я правильно понимаю, то JNA для С, а если есть C++ классы, то SWIG сгенерирует из них Ява классы, с которыми будете работать из Явы, а они будут переадресовывать все C++
В моем случае либа была на с++, но без классов, так что не совсем все так однозначно.
Написано немного кода для C++ и COM, но впринципе да — JNA для системных вызовов. В JNA есть довольно большая platform.jar с большим количеством имплементаций и тестов для Windows, включая сложные — секюрити, эвенты, этс.
Спасибо за пост, толкнул меня занятся JNA сайтом, всё заработало, извините за задержку — http://jna.java.net/
АААА! Так это Вы отвечаете за сайт?
Ну Вы злодей!
Вчера чуть не плакал когда на Яве писал колбэк, который вызывают из С с параметром char***!
A сайт — пустой!
Дошел до того, что скачал соурсы из мавен репозитория и ручками напускал на них javadoc.
И еще думал, как объясню нашему Legal, почему использую библиотеку у которй и сайта то нет нормального…
Ну Вы злодей!
Вчера чуть не плакал когда на Яве писал колбэк, который вызывают из С с параметром char***!
A сайт — пустой!
Дошел до того, что скачал соурсы из мавен репозитория и ручками напускал на них javadoc.
И еще думал, как объясню нашему Legal, почему использую библиотеку у которй и сайта то нет нормального…
Нет нет, я только один из злодеев. Нас много. Вы тоже можете стать со временем если будете продолжать в этом духе (посты про Жану на Хабре). Кстати сайт в сурсах, svn.java.net/svn/jna~svn/trunk/www.
Виноват Оракл конечно, нас устраивал и старый жава.нет. Кенай не сильно лучше…
Sign up to leave a comment.
JNA: callbacks to Java