Interfaz nativa de Java
| ||||||
La plataforma Java es relativamente nueva, lo que significa que algunas veces se necesita integrar programas escritos en Java con servicios, programas o APIs existentes desarrollados en lenguajes distintos. Es por ello que esta plataforma proporciona la Interfaz Nativa de Java, JNI por sus siglas en ingles, esta no es más que un framework de programación que permite que un programa escrito en Java ejecutado en la Máquina Virtual Java (JVM) pueda interactuar con programas escritos en otros lenguajes como C, C++ y ensamblador.
Sumario
Características
JNI es parte de la Máquina Virtual Java y permite invocaciones en ambos sentidos: aplicaciones Java pueden invocar código nativo escrito en otro lenguaje y viceversa, por lo que puede llamar a sistemas locales para realizar entrada / salida, gráficos, trabajos de red y operaciones de hilos de ejecución sobre el host del sistema operativo, tal como se muestra en la siguiente figura.
El JNI define una convención de nombres y llamadas para que la Máquina Virtual Java pueda localizar e invocar a los métodos nativos, quienes permiten solventar situaciones en las que una aplicación no puede ser enteramente escrita en Java, como por ejemplo en el caso de que la biblioteca standard de clases no proporcione soporte para funcionalidades dependientes de la plataforma.
Posibilita modificar programas existentes escritos en algún otro lenguaje, permitiéndoles ser accesibles desde aplicaciones Java. Muchas de las clases de la API estándar de Java dependen del JNI para proporcionar funcionalidad al desarrollador y al usuario, por ejemplo las funcionalidades de sonido o lectura/escritura de ficheros. El desarrollador debe asegurarse de que la API estándar de Java no proporciona una determinada funcionalidad antes de recurrir al JNI, ya que la primera ofrece una implementación segura e independiente de la plataforma.
El framework JNI permite a un método nativo utilizar los objetos Java de la misma forma en que el propio código de Java lo hace. Un método nativo puede crear objetos Java; y examinarlos y utilizarlos para que lleven a cabo su función. Un método nativo puede, asimismo, examinar y utilizar objetos que han sido creados por código de aplicación escrito en Java.
A menudo se denomina a JNI como la "válvula de escape" para desarrolladores dado que les permite añadir funcionalidades a sus aplicaciones que el API de Java no puede proporcionar.
Dado que, como se ha dicho antes, puede ser usado para interactuar con código escrito en otros lenguajes como C++, también se usa para operaciones y cálculos de alta complejidad temporal, porque el código nativo es por lo general más rápido que el que se ejecuta en una máquina virtual.
JNI también soporta una interfaz nativa, permitiendo incrustar una implementación de la máquina virtual dentro de aplicaciones nativas. Aplicaciones nativas pueden enlazarse con una biblioteca nativa que implementa la máquina virtual Java y luego usar la interfaz de invocación para ejecutar componentes escritas en lenguaje Java. Así es cómo un browser escrito en C puede ejecutar applets en una máquina virtual embebida.
Uso de JNI
Hay dos efectos secundarios del uso de JNI: Las aplicaciones que dependen de métodos nativos dejan de correr en otros ambientes. Se hace necesario re-hacer la biblioteca para cada ambiente. En segundo lugar se pierden algunas características del lenguaje, un mal comportamiento de un método nativo afecta toda la aplicación.
¿Qué pasa si el método nativo genera fuga de memoria?. Como regla general se debe limitar el uso de métodos nativos a un mínimo.
Se recomienda usar JNI cuando la aplicación requiere alguna característica del host no accesible a través de la máquina virtual, cuando se desea acceder a bibliotecas nativas, o cuando deseamos dar mayor velocidad a porciones críticas del código.
Existen alternativas a JNI que implican comunicación entre procesos. Por ejemplo cuando usamos la clase Runtime para ejecutar procesos nativos en forma concurrente. También podemos comunicar procesos vía TCP/IP o usar tecnologías para distribuir objetos como la API de Java IDL (Interface Description Language). En todos estos casos se sacrifica eficiencia por la necesaria comunicación entre procesos.
Usando JNI para invocar métodos nativos
En general el uso es simple, la mayor atención se debe poner en el paso de parámetros entre el método en Java y su implementación en C. Los pasos a seguir se resumen en la siguiente figura:
Funcionamiento de JNI
En JNI, las funciones nativas se implementan en archivos .c o .cpp por separado (C++ ofrece una interfaz con JNI ligeramente más clara). Cuando la máquina virtual invoca a la función, le pasa un puntero a JNIEnv, un puntero a jobject, y cualquier número de argumentos declarados por el método Java. Una función de JNI debería parecerse a esto:
JNIEXPORT void JNICALL Java_ClassName_MethodName
(JNIEnv *env, jobject obj)
{
//El método nativo se implementa aquí
}
El puntero JNIEnv *env es una estructura que contiene la interfaz hacia la máquina virtual. Incluye todas las funciones necesarias para interactuar con la JVM (Java Virtual Machine) y para trabajar con los objetos Java. Como ejemplos de uso de esta interfaz, se pueden mencionar la conversión de vectores (estilo C) de/a vectores Java o cadenas nativas (punteros a carácter) de/a cadenas Java (objetos String); instanciación de objetos, lanzamiento y captura de excepciones, etc. En esencia, usando JNIEnv puede hacerse cualquier cosa que el código Java pueda hacer; eso sí, con una dificultad considerablemente incrementada. Por ejemplo, el siguiente fragmento de código convierte una cadena de Java en una nativa.
//Código C++
JNIEXPORT void JNICALL Java_ClassName_MethodName
(JNIEnv *env, jobject obj, jstring javaString)
{
//Tomar la cadena nativa de la cadena de java
const char *nativeString = env->GetStringUTFChars(javaString, 0);
/* Libera el espacio ocupado por la cadena usada, esto tiene que ver con la forma en que Java maneja las cadenas */
env->ReleaseStringUTFChars(javaString, nativeString);
}
//C code
JNIEXPORT void JNICALL Java_ClassName_MethodName
(JNIEnv *env, jobject obj, jstring javaString)
{
//Tomar la cadena nativa de la cadena de java
const char *nativeString = (*env)->GetStringUTFChars(env, javaString, 0);
/*Libera el espacio ocupado por la cadena usada, esto tiene que ver con la forma en que Java maneja las cadenas */
(*env)->ReleaseStringUTFChars(env, javaString, nativeString); }
Nótese que el código JNI de C++ es sintácticamente más claro que el código en C, porque al igual que Java, C++ usa una semántica de invocación de métodos orientada a objetos, Esto implica que en C, el parámetro env debe ser desreferenciado usando (*env)-> y debe ser pasado explícitamente (aparece como parámetro) a los métodos de JNIEnv. En C++, el parámetro env se desreferencia usando env-> y se pasa implícitamente como parte de la semántica de invocación de métodos orientada a objetos (no aparece como parámetro porque el método forma parte de env cuando se trata como un objeto). Los tipos de datos nativos pueden sufrir conversiones desde/hacia tipos de datos Java. Para tipos complejos, tales como los objetos, arrays y cadenas, el método nativo debe convertir los datos explícitamente llamando a métodos en el JNIEnv (Java Native Interface Environment ).
Fuente
- JNI: Java Native Interface. Disponible en http://profesores.elo.utfsm.cl/~agv/elo330/2s09/lectures/JNI/jni.html
- Ventajas de usar archivos DLL. Disponible en http://msdn.microsoft.com/es-es/library/dtba4t8b.aspx.
