Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
| Содержание | Предыдущий | Следующий |
Эта глава представляет Java Собственный Интерфейс (JNI). JNI является собственным интерфейсом программирования. Это позволяет код Java, который работает в виртуальной машине Java (VM), чтобы взаимодействовать с приложениями и библиотеками, записанными в других языках программирования, таких как C, C++, и блок.
Самое важное преимущество JNI - то, что он не вводит ограничений для реализации базового Java VM. Поэтому, Java поставщики VM может добавить поддержку JNI, не влияя на другие части VM. Программисты могут записать одну версию собственного приложения или библиотеки и ожидать, что это будет работать со всем Java VMs поддержка JNI.
Эта глава затрагивает следующие темы:
В то время как можно записать приложения полностью в Java, есть ситуации, где один только Java не удовлетворяет потребности Вашего приложения. Программисты используют JNI, чтобы записать Java собственные методы, чтобы обработать те ситуации, когда приложение не может быть записано полностью в Java.
Следующие примеры иллюстрируют, когда Вы должны использовать Java собственные методы:
Программируя через JNI, можно использовать собственные методы для:
Можно также использовать JNI с API Вызова, чтобы позволить произвольному собственному приложению встроить Java VM. Это позволяет программистам легко подавать свои существующие заявки, поддерживающие Java, не имея необходимость соединяться с исходным кодом VM.
VMs от различных поставщиков предлагают различные собственные интерфейсы метода. Эти различные интерфейсы вынуждают программистов произвести, поддержать, и распределить многократные версии собственных библиотек метода по данной платформе.
Мы кратко исследуем некоторые из собственных интерфейсов метода, таких как:
JDK 1.0 был поставлен с собственным интерфейсом метода. К сожалению, было две главных причины, что этот интерфейс был неподходящим для принятия другим Java VMs.
Во-первых, собственный код поля, к которым получают доступ, в Java возражает как элементы структур C. Однако, Спецификация языка Java не определяет, как объекты размечаются в памяти. Если бы Java, VM размечает объекты по-другому в памяти, то программист должен был бы перекомпилировать собственные библиотеки метода.
Во-вторых, JDK 1.0’s собственный интерфейс метода, на который полагаются консервативный сборщик "мусора". Неограниченное использование unhand макрос, например, заставлял консервативно сканировать собственный стек.
Netscape предложил Интерфейс Среды выполнения Java (JRI), общий интерфейс для услуг, предоставленных в виртуальной машине Java. JRI был разработан с мобильностью в памяти---, это делает немного предположений о деталях реализации в базовом Java VM. JRI, адресуемый широкий диапазон проблем, включая собственные методы, отладку, отражение, встраивание (вызов), и так далее.
Java Microsoft VM поддерживает два собственных интерфейса метода. На низком уровне это обеспечивает эффективный Необработанный Собственный Интерфейс (RNI). RNI предлагает высокую степень обратной совместимости на уровне источника с собственным интерфейсом метода JDK, хотя у этого есть одно существенное различие. Вместо того, чтобы положиться на консервативную сборку "мусора", собственный код должен использовать функции RNI, чтобы взаимодействовать явно со сборщиком "мусора".
В более высоком уровне интерфейс Microsoft Java/COM предлагает независимый от языка стандартный двоичный интерфейс Java VM. Код Java может использовать COM-объект, как будто это был объект Java. Класс Java может также быть представлен остальной части системы как COM-класс.
Мы полагаем, что универсальный, хорошо продуманный стандартный интерфейс предлагает следующие преимущества для всех:
Лучший способ достигнуть стандартного собственного интерфейса метода состоит в том, чтобы включить все стороны с интересом к Java VMs. Поэтому мы организовывали ряд обсуждений среди лиц, имеющих патент Java на проекте универсального собственного интерфейса метода. Это является четким из обсуждений, что стандартный собственный интерфейс метода должен удовлетворить следующие требования:
Мы надеялись принять один из существующих подходов как стандартный интерфейс, потому что это наложит наименьшее количество бремени на программистов, которые должны были изучить многократные интерфейсы в различном VMs. К сожалению, никакие существующие решения не являются абсолютно удовлетворительными в достижении наших целей.
JRI netscape является самым близким к тому, что мы предполагаем как переносимый собственный интерфейс метода, и использовался в качестве начальной точки нашего проекта. Читатели, знакомые с JRI, заметят общие черты в соглашении о присвоении имен API, использовании метода и полевых ID, использовании локальных и глобальных ссылок, и так далее. Несмотря на наши максимальные усилия, однако, JNI не является совместимым с двоичным файлом с JRI, хотя VM может поддерживать и JRI и JNI.
RNI Microsoft был улучшением по сравнению с JDK 1.0, потому что это решило проблему собственных методов, работающих с неконсервативным сборщиком "мусора". RNI, однако, не был подходящим как собственный интерфейс метода VM-independent. Как JDK, RNI собственный Java доступа методов возражает как C структуры, приводя к двум проблемам:
Как двоичный стандарт, COM гарантирует полную совместимость на уровне двоичных кодов через различный VMs. Вызов метода COM требует только косвенного вызова, который переносит небольшие издержки. Кроме того, COM-объекты являются большим улучшением по сравнению с динамически подключаемыми библиотеками в решении проблем управления версиями.
Использованию COM как стандартный Java собственный интерфейс метода, однако, препятствуют несколько факторов:
Хотя объекты Java не представляются собственному коду как COM-объекты, интерфейс самого JNI является совместимым с двоичным файлом с COM. JNI использует ту же самую структуру таблицы переходов и соглашение о вызовах, которое делает COM. Это означает, что, как только межплатформенная поддержка COM доступна, JNI может стать интерфейсом COM к Java VM.
JNI, как полагают, не является единственным собственным интерфейсом метода, поддерживаемым данным Java VM. Стандартный интерфейс приносит пользу программистам, которые хотели бы загрузить их собственные библиотеки кода в различный Java VMs. В некоторых случаях программисту, вероятно, придется использовать интерфейс VM-specific низшего уровня, чтобы достигнуть главной эффективности. В других случаях программист мог бы использовать высокоуровневый интерфейс, чтобы создать компоненты программного обеспечения. Действительно, поскольку среда Java и технологии компонентного программного обеспечения становятся более зрелыми, собственные методы, будет постепенно терять их значение.
Собственные программисты метода должны программировать к JNI. Программирование к JNI изолирует Вас от unknowns, такого как VM поставщика, который мог бы выполнять конечный пользователь. Соответствуя стандарту JNI, Вы дадите собственной библиотеке лучшую возможность выполнить в данном Java VM.
Если Вы реализуете Java VM, следует реализовать JNI. JNI был временем, протестированным и обеспеченным, чтобы не наложить любые издержки или ограничения на Вашу реализацию VM, включая объектное представление, схему сборки "мусора", и так далее. Пожалуйста, отправьте нам свой отклик, если Вы сталкиваетесь с какими-либо проблемами, мы, возможно, пропустили.
С Java SE 6.0, осуждаемые структуры JDK1_1InitArgs и JDK1_1AttachArgs были удалены, вместо этого JavaVMInitArgs и JavaVMAttachArgs должны использоваться.
| Содержание | Предыдущий | Следующий |
