Comments 16
Кстати, а libc++ имеет шансы собраться на Андроиде? Там хорошая поддержка C++11, да и либа почище в плане кода чем libstdcpp.
Насколько я заметил, эта библиотека и под обычными системами ещё толком не работает. Есть ли смысл еёпортировать на Андроид? Там у них более приоритетные версии есть. Хотя при желании конечно запортировать можно все, что угодно. Чем собственно сейчас и занимаюсь.
Под макосью она используется в с++11 режиме и вполне радует.
Если очень хочется, можно портировать, кто бы только взялся?
Если у исходников нормальная система сборки, желательно make — она лучше всего согласуется с *.mk, то построить её под Android, думаю не составит особого труда. 4 аналогичных примера уже есть в составе NDK
Если у исходников нормальная система сборки, желательно make — она лучше всего согласуется с *.mk, то построить её под Android, думаю не составит особого труда. 4 аналогичных примера уже есть в составе NDK
Там cmake, с ним вроде бы особых сложностей для Андроида нет, но она вроде как собирается clang'ом, поэтому видимо придется вначале его ещё собрать.
Хотя есть впечатление, что оно должно просто взять и заработать. Ибо когда еще давно в libcxx не была заявлена еще поддержка linux, она прекрасно собиралась и работала.
Хотя есть впечатление, что оно должно просто взять и заработать. Ибо когда еще давно в libcxx не была заявлена еще поддержка linux, она прекрасно собиралась и работала.
Можно подробнее о работе с Java-исключениями в native?
А что конкретно интересует? Обработка исключений в ява машине стандартна: после вызова каждого метода JNI environment делаем checkException() и по желанию describeException(). Это всё подробно описано в JNI specification.
Здесь я только акцентировал внимание на способе удобной обёртки ява ошибок в плюсовые и обратно, поскольку частенько приходится менять контекст выполнения с байткода в натив и обратно.
Здесь я только акцентировал внимание на способе удобной обёртки ява ошибок в плюсовые и обратно, поскольку частенько приходится менять контекст выполнения с байткода в натив и обратно.
Интересует, как именно
Я подобную задачу когда-то решал, но получилось многовато некрасивого кода. Думал, может у вас вышло лучше.
все ява исключения в нативе перехватываются и оборачиваются наследниками std::exception, особенно если исключение нельзя обработать и приходится посылать из native-метода обратно в Java.
Я подобную задачу когда-то решал, но получилось многовато некрасивого кода. Думал, может у вас вышло лучше.
Можете примерами кода показать связку? А то я читал статью, но мысль не ухватил (хотя сам занимаюсь тем же самым).
Вообще говоря это коммерческий продукт, но возможно что-то можно выложить
Давайте лучше так, что конкретно хотелось бы уточнить?
«конвертировать поток выполнения», «Все Ява объекты, при привязке их к нативу» — что вы имеете ввиду?
«обратые методы для доступа к полям объекта в 3 раза менее производительны, чем прямой вызов» — чьи методы? к полям какого объекта? прямой вызов откуда?
После этого у нас готов к работе Ява-объект, его нативные методы автоматом идут через JNI, а там в свою очередь достается указатель на нативный объект, он кастуется и вызывает соответствующий метод C++.
покажите структуру этого Ява-объекта в коде .java хотя-бы с одним нативным методом, что значит нативные методы автоматом идут через JNI? Где достается указатель на нативный объект?
«обратые методы для доступа к полям объекта в 3 раза менее производительны, чем прямой вызов» — чьи методы? к полям какого объекта? прямой вызов откуда?
После этого у нас готов к работе Ява-объект, его нативные методы автоматом идут через JNI, а там в свою очередь достается указатель на нативный объект, он кастуется и вызывает соответствующий метод C++.
покажите структуру этого Ява-объекта в коде .java хотя-бы с одним нативным методом, что значит нативные методы автоматом идут через JNI? Где достается указатель на нативный объект?
Поток выполнения (control flow) — стандартное понятие. В нашем случае он происходит на 2-х уровнях: на верхнем уровне байткода и нижнем нативном. При переходе из одного в другой приходиться все данные преобразовывать из одного представления в другое, это я и называю конвертированием.
«при привязке их к нативу» — имеется в виду использование ява-объекта с нативными методами. В моем случае реализация этих методов находится в соответствующих плюсовых объектах. То есть ява-объекты считаются привязанными к нативу, если им в соответствие есть нативная функия. Всё просто.
Пример:
Привязывается на функции
А они в свою очередь обращаются к методам
Эта привязка называется прямым вызовом (на developerworks, т.к. jvm непосредственно зовет эти методы с передачей им аргументов). Обратный вызов — из натива в jvm — производится через явовские коллбэки. Подробнее можно прочитать здесь
Указатель на нативный объект достается в функциях Java_Foo_*одним коллбэком. Это пока что одно из неэффективных решений. По хорошему этот указатель можно сразу передавать в качестве параметра, но я не хотел захламлять интерфейсы в яве.
«при привязке их к нативу» — имеется в виду использование ява-объекта с нативными методами. В моем случае реализация этих методов находится в соответствующих плюсовых объектах. То есть ява-объекты считаются привязанными к нативу, если им в соответствие есть нативная функия. Всё просто.
Пример:
class Foo extends NativeObject{
native void exec();
native int calc();
}
Привязывается на функции
JNIEXPORT void Java_Foo_exec();
JNIEXPORT jint Java_Foo_calc();
А они в свою очередь обращаются к методам
class Foo: public NativeObject{
void exec();
int calc();
}
Эта привязка называется прямым вызовом (на developerworks, т.к. jvm непосредственно зовет эти методы с передачей им аргументов). Обратный вызов — из натива в jvm — производится через явовские коллбэки. Подробнее можно прочитать здесь
Указатель на нативный объект достается в функциях Java_Foo_*одним коллбэком. Это пока что одно из неэффективных решений. По хорошему этот указатель можно сразу передавать в качестве параметра, но я не хотел захламлять интерфейсы в яве.
-
Sign up to leave a comment.
Самопальная привязка С++ классов к JVM через JNI