Комментарии 9
Извиняюсь спросить, но зачем нужно такое скрещивание? Если только для того, чтоб на java нарисовать интерфейс программы, то у python есть куча вариантов интерфейсов, например WX widgets, или другие. Если чтоб запускать без установки на других компах pythonа, то всегда можно собрать exe-шник pyinstaller или еще чем. А вот для чего запускать python приложение из java приложения — не могу придумать вообще.
Работа с Python — это просто пример. Проект Panama позволяет работать с любым нативным кодом, включая пакеты линейной алгебры, написанные на Fortran, графические библиотеки, типа OpenGL, библиотеки машинного обучения, типа Tensorflow, криптографические библиотеки, системные и т.п. Не всё можно реализовать на Java, и не всегда реализации на Java получаются в достаточной степени производительными, поэтому невозможно обойтись без интероперабельности с нативным кодом. Раньше для этого применялся JNI, но он слишком сложный и недостаточно быстрый. Проект Panama исправляет оба этих недостатка.
А, понял, спасибо за разъяснение. После статьи как-то не уловил данных возможностей.
Насколько я помню, при работе с JNI много ресурсов тратится именно на бридж между Java и нейтивом. А как тут эту проблему решили?
Честно говоря, с деталями не знаком. Документации пока очень мало, а в код я ещё не погружался. Но судя по прослушанным докладам, к этому вопросу комплексный подход, JVM изменяют под «Панаму» сразу во многих местах — не такая тесная интеграция нативного кода с JVM, передача в нативный код только off-heap данных, большее количество информации о нативных вызовах у JIT-компилятора и т.д. и т.п.
Приведу пример из своей работы. Нужно строить дерево какого-то железа (эта железка может иметь этих детей в таком-то количестве, а вот эта- совсем других детей и.т.д.) Железо на момент изготовления программы неизвестно, что куда подключается- неизвестно. Сначала пытались выехать на описалове и настройках, но уж больно всё сложно всё получалось, и потому решили внедрить скрипты в описалово железа. И всё прям замечательно получилось — считываешь json-ку, находишь по id нужную железку, запускаешь скрипт и получаешь, что к этой железке можно подключить, а что-нет. Для скриптов используем groovy
А есть какие-нибудь бенчмарки, насколько оно быстрее чем jni?
Есть хорошее видео от JVM разработчика, который принимает участие в этом проекте. И хорошо проходит по теме «native» вызовов/памяти. На 29 минуте есть небольшое сравнение между JNI и «улучшенным вариантов».
https://www.youtube.com/watch?v=sFxrjGTnvBs
https://www.youtube.com/watch?v=sFxrjGTnvBs
Пока рано измерять, так как Panama на ранних стадиях разработки. В Early-Access билдах Panama не совсем настоящая, foreign function calls делаются поверх JNI, так же как это делает JNA. Но одна из основных целей, поставленных перед проектом с самого начала — быть быстрее JNI и sun.misc.Unsafe. Маурицио Чимадаморе в докладе "Project Panama’s Foreign API" рассказывает, что в те редкие моменты, когда боевой бэкенд не падает объятый пламенем, он показывает результаты в несколько раз лучшие, чем JNI, и есть потенциал для ускорения в десятки раз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встраиваем интерпретатор Python в java-приложение с помощью проекта Panama