Процедуры, обеспечивающие связь native-метода с программой на Java, зависят от применяемой операционной системы и языка программирования, на котором native-методы реализованы. Рассмотреть все или хотя бы наиболее распространенные языки операционные системы в рамках журнальной статьи не представляется возможным. Поэтому я остановлюсь на связи языка Java с библиотеками DLL операционных систем семейства Microsoft Windows.

Представим, что в программе на языке Java есть метод с именем nativeMethod(), который де-факто является native-методом и реализован в какой-то динамической библиотеке. Для того, чтобы указать, что метод nativeMethod() является native-методом, при его объявлении необходимо использовать ключевое слово native. Например, это объявление может выглядеть следующим образом:


public native int nativeMethod();

Естественно, что для использования native-метода необходимо загрузить ту библиотеку, в состав которой он входит. Для этого программа на Java может воспользоваться методами load и loadLibrary(), входящими в состав класса System.

Это – все, что необходимо сделать в Java-программе для обеспечения вызова native-метода. Приведем пример объявления и вызова native-метода. При этом допустим, что файл называется Example.java и что native-метод должен быть реализован в библиотеке с именем Article.dll:


public class Example
{
public static void main( String args[] )
{
Example ex = new Example();
System.out.println( "Before native method call." );
int result = ex.nativeMethod();
System.out.println( "After native method call." );
System.out.println( "Result = " + result );
}
public native int nativeMethod();
static
{
System.load( "f:/Article/Example/Article.dll" );
}
}

Откомпилировав этот файл и, соответственно, содержащийся в нем класс, мы получим файл Example.class. Однако, несмотря на то, что класс откомпилировался без ошибки, он пока неработоспособен, так как до сих пор не установлена связь с native-методом. Для того, чтобы установить эту связь, придется проделать некоторую работу.

Подготовка native-метода к вызову из языка Java

Во-первых, при компиляции native-метода компилятор языка Java производит некоторые вспомогательные действия, результатом которых, в частности, является то, что при вызове native-метода к списку аргументов последнего добавляются некоторые величины, существование которых игнорировать нельзя. Для того чтобы определить, как будет выглядеть интерфейс вызова native-метода, следует воспользоваться утилитой javah (вероятно, сокращение от Java’s Header), которая входит в состав JDK. Все аргументы этой утилиты описаны в ее документации. Нам сейчас важно понять, что эта утилита обрабатывает ранее откомпилированный java-класс, который находится в файле, имя которого совпадает с именем класса.

Аргументом при вызове утилиты должно быть имя класса, в котором описан native-метод. Отыскав в этом классе вызов native-метода, утилита определяет, с каким аргументами будет вызван native-метод, после чего формирует файл заголовка (.h-файл), который должен быть включен в С-файл, в котором будет находиться реализация метода nativeMethod().

Итак, применительно к нашему примеру утилиту javah необходимо вызвать следующим образом:
javah Example

Результатом работы утилиты будет файл Example.h, который приведен ниже:


/* DO NOT EDIT THIS FILE - it is machine generated */
#include 
/* Header for class Example */

#ifndef _Included_Example
#define _Included_Example
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: Example
* Method: nativeMethod
* Signature: ()I
*/
JNIEXPORT jint JNICALL Java_Example_nativeMethod (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif

Что мы можем узнать, взглянув на этот файл? Во-первых, то, что в состав программы на С будет включен заголовочный файл jni.h, в котором, кстати, содержатся все необходимые для работы JNI описания.
Во-вторых, мы увидим, что тот метод, который в классе Example был описан как


public native int nativeMethod();

в программе на C должен быть описан несколько по-другому, а именно как


JNIEXPORT jint JNICALL Java_Example_nativeMethod (JNIEnv *, jobject);

Определение JNIEXPORT в файле jni_md.h, который вызывается из jni.h, описано следующим образом:


#define JNIEXPORT __declspec(dllexport)

Описание вполне понятно и я не стану тратить время и внимание читателя на объяснение очевидных вещей. В том же файле определение JNICALL описано так:


#define JNICALL __stdcall

После этого становится понятным, что все эти «страшные» описания являются просто обозначениями, используемыми при вызове обычной экспортируемой функции.

Что же касается описания «jint», то в файлах jni.h и jni_md.hопределены несколько простых типов, которые могут быть использованы при написании native-методов. Я приведу их в таблице 1.

Определение	Тип
typedef unsigned char	Boolean
typedef unsigned short	Jchar
typedef short	Jshort
typedef float	Jfloat
typedef double	Jdouble
typedef long	Jint
typedef __int64	Jlong
typedef signed char	Jbyte

Таблица 1.

Вспомним также, что программа на С для вызова из программы на Java должна содержать не функцию nativeMethod(), а функцию Java_Example_nativeMethod(). Вероятно, новое имя функции показывает, что она принадлежит классу Example, который, в свою очередь, является классом Java. Очень важно и то, что у этой функции должно быть два аргумента. Первым аргументом функции является указатель на «среду» JNI. Описание этой «среды» находится в файле jni.h, оно достаточно объемно, поэтому, к сожалению, нет возможности привести его здесь. Второй аргумент – это аналог указателя «this» в C, то есть подобие указателя на объект, из которого произведен вызов native-метода. Об этих аргументах мы поговорим немного позже. Но уже сейчас нам известно достаточно для того, чтобы написать native-метод и вызвать его из класса Java. Ниже приведен исходный текст программы Article.cpp, в которой определен native-метод, предназначенный для вызова из программы на языке Java:


#include 
#include 
#include 
#include "Example.h"

BOOL APIENTRY DllMain( HANDLE hModule, 
                      DWORD ul_reason_for_call, LPVOID lpReserved)
{
return TRUE;
}

JNIEXPORT jint JNICALL Java_Example_nativeMethod (JNIEnv * je, 
                                                  jobject jo)
{
printf( "!!! In the native method !!!\n" );
return 32;
}

Результатом компиляции этого файла будет файл Article.dll. А результатом работы класса Example, осуществляющего вызов метода из библиотеки Article.dll, будет следующий вывод:


Before native method call.
!!! In the native method !!!
After native method call.
Result = 32

Приведенный выше результат работы программы показывает, что, с одной стороны, отработала функция (native-метод), находящаяся в библиотеке, написанной на C (именно она выдает сообщение «!!! In the native method !!!»). С другой стороны, класс на языке Java получил результат выполнения native-метода и отобразил его.

Однако все, о чем говорилось выше, касается только для тех native-методов, которые программист может написать сам. А как же быть в случае, когда native-методы находятся в библиотеке, к исходным текстам которой программист доступа не имеет? В таком случае процесс обращения к native-методу состоит из двух этапов. Во-первых, необходимо создать «промежуточную» библиотеку на языке C/C++, в которой будут реализованы методы с именами и аргументами, подготовленными к вызову из программы на языке Java. Во-вторых, из этой промежуточной библиотеки должны вызываться методы и функции, находящиеся в уже готовой библиотеке. Так как «промежуточная» библиотека написана на языке С/С++, то ничто не мешает обратиться к функциям, находящимся в другой библиотеке, обычным образом, а результаты работы передать в программу на языке Java.

Вызов методов класса Java из native-кода

Итак, как показано выше, вызов native-методов и получение результата их выполнения из программы на языке Java возможно. Возникает вопрос: а что представляют собой передаваемые native-методу аргументы? Что такое «среда» JNI? Что представляет собой объект Java с точки зрения практического использования?

Фактически «среда» JNI представляет собой массив указателей на методы, используя которые можно осуществлять доступ к полям класса Java и осуществлять вызов методов класса Java (как класса, из которого вызывается native-метод, так и любого Java-класса, подробнее см. в конце статьи). Передаваемый же native-методу объект позволяет осуществить привязку методов JNI непосредственно к конкретному объекту и классу объектов, с которыми может работать native-метод. Продемонстрируем это на практике.

Технология получения native-методом значения поля, принадлежащего классу Java, состоит в следующем. Во-первых, необходимо получить указатель на класс, к которому относится объект, осуществивший вызов native-метода. Это можно сделать при помощи метода GetObjectClass(), входящего в состав «среды» JNI. В том случае, если native-метод реализован на языке C++, этому методу передается только полученный native-методом объект (второй аргумент при вызове native-метода). В случае написания native-метода на языке C аргументами метода являются указатель на «среду» JNI (первый аргумент при вызове native-метода) и переданный native-методу объект. Прототипы метода GetObjectClass() для языков C и С++ соответственно, взятые из файла jni.h, приведены ниже:


jclass (JNICALL *GetObjectClass) (JNIEnv *env, jobject obj); // C
jclass GetObjectClass(jobject obj) 
    {return functions->GetObjectClass(this,obj); } // C++

Во-вторых, получив указатель на класс, необходимо получить идентификатор поля объекта Java, доступ к которому необходимо получить из native-метода. Это делается при помощи входящего в состав «среды» JNI метода GetFieldID(). Прототипы этих методов, приведенные ниже, также находятся в файле jni.h:


jfieldID (JNICALL *GetFieldID) 
(JNIEnv *env, jclass clazz, const char *name, const char *sig);

jfieldID GetFieldID(jclass clazz, const char *name, const char *sig)
{
return functions->GetFieldID(this, clazz, name, sig);
}

В этом случае аргументы методов не столь очевидны, как в случае GetObjectClass(). Думаю, что аргументы env и clazz понятны без объяснений. Аргумент name представляет собой имя поля, значение которого необходимо получить. А что представляет собой поле sig?

Дело в том, что у каждого поля и метода класса, реализованного на языке Java, есть не только имя, но и так называемая сигнатура. Для того, чтобы получить эту сигнатуру, можно воспользоваться утилитой javap, вызвав ее с опцией -s и передав ей в качестве аргумента имя класса, сигнатуры которого нужно получить. В частности, для класса Example, приведенного выше, утилита javap выдала следующий результат:


Compiled from Example.java
public class Example extends java.lang.Object {
int i;
/* I */
public Example();
/* ()V */
public static void main(java.lang.String[]);
/* ([Ljava/lang/String;)V */
public void printMessage();
/* ()V */
public native int nativeMethod();
/* ()I */
static {};
/* ()V */
}

Отсюда видно, что сигнатура поля i равна «I». Передав методу GetFieldID() сигнатуру поля в качестве последнего аргумента, мы получим идентификатор поля. Но это еще не все. Для того чтобы получить значение поля, следует обратиться к методу


GetIntField():
jint (JNICALL *GetIntField)
(JNIEnv *env, jobject obj, jfieldID fieldID);

jint GetIntField(jobject obj, jfieldID fieldID)
{
return functions->GetIntField(this, obj, fieldID);
}

Возвращенное этим методом значение и будет являться тем значением поля, которое мы хотим получить.
Замечу, что общее название группы методов, позволяющих получить значение поля – GetField.
Для того чтобы из native-метода вызвать метод, определенный в вызывающем классе, нужно затратить усилий не меньше, чем для того, чтобы получить значение поля. Во-первых, при помощи метода GetMethodId() следует получить идентификатор метода. Прототипы метода GetMethodId() приведены ниже:


jmethodID (JNICALL *GetMethodID) (JNIEnv *env, 
  jclass clazz, const char *name, const char *sig);

jmethodID GetMethodID(jclass clazz, const char *name, const char *sig)
{
return functions->GetMethodID(this, clazz, name, sig);
}

Думаю, что назначения аргументов методов не должны вызывать вопросов. Метод возвращает идентификатор метода в классе. Зная этот идентификатор, можно обратиться к методу при помощи одного из методов группы CallMethod(). В данном случае нужно обратиться к методу printMessage(), не возвращающему значения, поэтому целесообразно воспользоваться методом CallVoidMethod():


void (JNICALL *CallVoidMethod)
(JNIEnv *env, jobject obj, jmethodID methodID, ...);

void CallVoidMethod(jobject obj, jmethodID methodID, ...) {
va_list args;
va_start(args,methodID);
functions->CallVoidMethodV(this,obj,methodID,args);
va_end(args);
}

Ниже приведен исходный текст класса Java, значение поля i которого будет получено в native-методе и метод printMessage() которого будет вызван из native-метода:


public class Example
{
int i;

public static void main( String args[] )
{
Example ex = new Example();
ex.i = 28;
System.out.println( "Before native method call." );
int result = ex.nativeMethod();
System.out.println( "After native method call." );
System.out.println( "Result = " + result );
}

public void printMessage()
{
System.out.println( "This method was called from native method." );
}

public native int nativeMethod();

static
{
System.load( "f:/Article/Example/Article.dll" );
}
}

Исходный текст DLL, в которой находится код, осуществляющий доступ к полю класса Example и вызывающий метод printMessage(), также приведен ниже:


#include "stdafx.h"
#include 
#include "Example.h"

BOOL APIENTRY DllMain( HANDLE hModule, 
                DWORD ul_reason_for_call, LPVOID lpReserved)
{
return TRUE;
}

JNIEXPORT jint JNICALL Java_Example_nativeMethod
(JNIEnv *je, jobject jo)
{
jclass javaClass;
jfieldID javaFieldID;
jmethodID javaMethodID;

printf( "!!! In the native method !!!\n" );
javaClass = je->GetObjectClass( jo );
javaFieldID = je->GetFieldID( javaClass, "i", "I" );
printf( "i = %d.\n", je->GetIntField( jo, javaFieldID ) );
javaMethodID = je->GetMethodID( javaClass, "printMessage", "()V" );
printf( "javaMethodID = %x.\n", javaMethodID );
je->CallVoidMethod( jo, javaMethodID );
printf( "!!! About to leave the native method !!!\n" );
return 123;
}

Результат работы связки «класс Example <-> native-метод Java_Example_nativeMethod» был следующим:


Before native method call.
!!! In the native method !!!
i = 28.
javaMethodID = 6ac790.
This method was called from native method.
!!! About to leave the native method !!!
After native method call.
Result = 123

Проанализировав приведенный выше результат, можно заметить, что первое сообщение выдается классом Example. Cледующие пять строк выдаются native-методом. При этом строка, начинающаяся с «This method…», выдана методом класса Example, вызванным из native-метода. И, наконец, последние два сообщения выдаются опять-таки классом Example. Связь между классом Java и native-методом налицо.

Заключение

Естественно, описанными выше возможностями интерфейс JNI не ограничивается. В частности, native-метод может получить идентификатор любого класса при помощи метода FindClass(), после чего создать объект этого класса при помощи метода NewObject() и обращаться к методам созданного объекта при помощи методов группы CallMethod(). Таким образом, возможности по связи классов языка Java и native-методов являются практически неограниченными.

Однако в каждой бочке меда есть своя ложка дегтя. Дело в том, что использование в языке Java native-методов нарушает принцип многоплатформенности языка Java. Программа, использующая DLL, становится заведомо «привязанной» к платформе, на которой реализована DLL. Использование native-методов можно порекомендовать в тех случаях, когда предполагается использование основной программы (класса Java) на разных платформах, в то время как машинно- или платформенно-зависимые части программы в виде native-методов планируется разработать для каждой конкретной платформы. Если программу на Java, использующую native-методы, планируется применять только на той платформе, на которой реализованы native-методы, то такая затея заведомо является бессмысленной.

И еще один, более серьезный аргумент против native-методов. Native-код может получить доступ к любой части системы, что в принципе является небезопасным. Поскольку одним из требований, предъявляемых к языку Java, является требование безопасности, применение native-методов опять-таки идет вразрез с идеологией языка Java.

Тем не менее, ответственность за принятие решения о применении в программе на Java native-методов, расширяющих стандартные возможности Java, лежит на программисте.

Автор: Павел Румянцев

[ вверх ]

Комментарии

Ваш комментарий к данному материалу будет интересен нам и нашим читателям!

+ Добавить комментарий

Последние статьи: Программирование под ОС / Java /

Особенности Java 5

23-02-2010

Java 5 обладает некоторыми полезными возможностями. В данной статье мы рассмотрим их и узнаем, как можно извлечь из них выгоду. В этой части мы рассмотрим auto-boxing foreach... подробнее

Комментарии: 0

Кол. просмотров: общее - 5761 сегодня - 0

Особенности Java 5. Часть 2

23-02-2010

В первой части мы обсудили новые возможности Java 5 относительно функции auto-boxing и цикла foreach. В данной части мы обсудим поддержку функций с переменным числом аргументов и статическое импортирование (static import). Поскольку другие функции, такие как enum, annotation, и generics, заслуживают отдельной статьи, мы их не будет демонстрировать в данной... подробнее

Комментарии: 0

Кол. просмотров: общее - 4872 сегодня - 0

Расширение функциональности элементов пользовательского интерфейса в Java

05-05-2009

Довольно часто при создании приложений с GUI (stand alone приложений или апплетов) приходится сталкиваться с необходимостью несколько изменить внешний вид и поведение стандартных компонентов пользовательского интерфейса... подробнее

Комментарии: 5

Кол. просмотров: общее - 5111 сегодня - 0

Введение в сервлеты

05-05-2009

Что такое сервлет ? Это класс порожденный от класса HttpServlet с переопреденными методами doGet и doPost (управление приходит в один из этих методов в зависимости от того какого типа был запрос. Надеюсь у Вас есть некоторый опыт в cgi-программировании... подробнее

Комментарии: 0

Кол. просмотров: общее - 5070 сегодня - 1

Java Server Pages

05-05-2009

Технология Java Server Pages (JSP) является составной частью единой технологии создания бизнес-приложений J2EE. JSP - это альтернативная методика разработки приложений... подробнее

Комментарии: 0

Кол. просмотров: общее - 4830 сегодня - 0