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 class может также быть представлен остальной части системы как class 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. Мы используем ту же самую структуру таблицы переходов и соглашение о вызовах, которое делает COM. Это означает, что, как только межплатформенная поддержка COM доступна, JNI может стать COM-интерфейсом к Java VM.
Мы не полагаем, что JNI должен быть единственным собственным интерфейсом метода, поддерживаемым данным Java VM. Стандартный интерфейс приносит пользу программистам, которые хотели бы загрузить их библиотеки собственного кода в различный Java VMs. В некоторых случаях программисту, вероятно, придется использовать интерфейс VM-specific низшего уровня, чтобы достигнуть главной эффективности. В других случаях программист мог бы использовать высокоуровневый интерфейс, чтобы создать компоненты программного обеспечения. Действительно, мы надеемся, что, поскольку среда Java и технологии компонентного программного обеспечения становятся более зрелыми, собственные методы, будет постепенно терять их значение.
Собственные программисты метода должны начать программировать к JNI. Программирование к JNI изолирует Вас от unknowns, такого как VM поставщика, который мог бы выполнять конечный пользователь. Соответствуя стандарту JNI, Вы дадите собственной библиотеке лучшую возможность выполнить в данном Java VM. Например, хотя JDK 1.1 будет продолжать поддерживать собственный интерфейс метода старого стиля, который был реализован в JDK 1.0, точно будущие версии JDK прекратят поддерживать собственный интерфейс метода старого стиля. Должны будут быть переписаны собственные методы, полагающиеся на интерфейс старого стиля.
Если Вы реализуете Java VM, следует реализовать JNI. Мы (Javasoft и лица, имеющие патент) старались изо всех сил гарантировать, что JNI не налагает издержек или ограничений на Вашу реализацию VM, включая объектное представление, схему сборки "мусора", и так далее. Пожалуйста, сообщите нам, сталкиваетесь ли Вы с какими-либо проблемами, мы, возможно, пропустили.
Чтобы лучше поддерживать среду выполнения Java (JRE), API Вызова был расширен в JDK 1.1.2 несколькими незначительными способами. Изменения не повреждают существующего кода. JNI Собственный Интерфейс Метода не был изменен.
name=value
указание на системное свойство. (Это средство соответствует-D опции в командной строке java.)
| Содержание | Предыдущий | Следующий |
