SemtexGirl

O SD Best Practices é uma conferência onde os principais players da comunidade de desenvolvimento de software se reúnem para aprender sobre as últimas tecnologias, e se encontram com os principais vendedores da indústria. A conferência é um treinamento centrado em fornecer as ferramentas necessárias para adoação com êxito em seus projetos das melhores práticas de design, qualidade e técnicas de gerenciamento de projeto.

Com uma programação com 142 sessões apresentadas em 6 formatos (Birds-of-a-Feather Gathering, Estudo de Caso, Classe, Experimental, Mesa Redonda, Tutorial) separados em 10 tracks( Algoritmos Avançados & Conceitos, Processo Ágil & Metodologia, C++, Design & Arquitetura, Linguagem & Implementação, Pessoas, Projetos & Times, Requisitos & Analise, Secure Design, Teste & Qualidade, Web Services/SOA) o SD Best Practices é uma maratona de 5 dias que começa na próxima segunda-feira, 27 de outubro e termina na sexta-feira dia 30 de outubro das 8:30 as 17:00

Solicitação aprovada, passagens compradas, hotel reservado, visto aprovado, agora é fato, Boston aqui vou eu!

Empresas americanas gastam mais de US$275 bilhões a cada ano em projetos de desenvolvimento de software aplicativo. Muitos desses projetos falharão, mas não por falta de dinheiro ou tecnologia; a maioria falhará por falta de um gerenciamento de projetos habilidoso.

Ao desenvolvermos uma aplicação em JNI o acesso aos membros de uma classe é normalmente realizado através das próprias funções JNI, em vez de permitir acesso direto aos membros nativos. Este procedimento tem uma vantagem e um inconveniente:

• Vantagem: Os objetos apontados por referencias são visto de forma simples pelo programador.
• Inconveniente: Impacto no desempenho

Este impacto no desempenho se vê atenuado com a utilização de métodos nativos apenas para realizar funções não triviais, é por este motivo que não costumamos usa-los para realizar operações triviais, exceto é claro em exemplos como neste artigo.

Desempenho acessando arrays

Quando trabalhamos com arrays múltiplos não é viável o uso de função para acessarmos cada elemento de um array, no intuito de resolver este problema foi desenvolvida uma solução chamada ‘pinning’, que consiste em um método nativo que pede a maquina virtual que não remova da memória o conteúdo de um array, desta forma o método nativo pode obter o ponteiro que aponta diretamente para o conteúdo de um array. Esta solução, entretanto, tem duas implicações:

• O garbage coletor deve suportar ‘pinning’. Em muitas implementações é inviável utilizar ‘pinning’ pois complica o garbage coletor e induz � fragmentação da memória.
• A máquina virtual deve posicionar as primitivas contiguamente na memória. Embora esta seja a disposição natural para array de tipos primitivos, os arrays booleanos podem ser implementados como empacotados e desempacotados. Uma disposição booleana empacotado usa um bit para cada elemento, visto que desempacotado usa tipicamente um byte para cada elemento. Conseqüentemente, o código nativo que confia na disposição exata dos arrays booleanos perdera sua portabilidade.

E através das funções do tipo GetArrayElements() podemos apenas obter ponteiros de tipo primitivos de dados, os arrays de objetos devem ser acessados individualmente usando GetObjectArrayElement().

Ainda assim GetArrayElements() não nos garante a obtenção do ponteiro do array original uma vez que ele cria uma cópia em outra área de memória, em resumo esta decisão depende de:

Que o garbage colector suporte “pinning”, no qual implica que o objeto não pode ser liberado ainda que não seja uma referência Java e para que o JNI o libere é preciso executar a função ReleaseArrayElements().

A distribuição dos elementos de um array na memória, assim como o seu tamanho sejam os mesmos do C.

De outra forma o array será copiado para outra área de memória e será formatado convenientemente.

Atento ao fato de que só quando chamamos a função ReleaseArrayElements() que a máquina virtual finaliza o pinning, deixando livre uma cópia do array.

Outra solução que foi incorporada ao JSDK 1.2 as funções GetPrimitiveArrayCritical() e ReleasePrimitiveArrayCritical(), ao uso destas funções são recomendadas sempre que uma thread não:

• Possuir um processo de tempo indefinido
• Chamar outras funções JNI
• Realizar uma operação “thread sleep” (suspensão da execução da thread por um tempo determinado)

Cumprindo estas condições a máquina virtual pode desativar temporariamente o garbage colector enquanto o método nativo acessa diretamente o array, sem que a máquina virtual use pinning. Isto aumenta a possibilidade da máquina virtual retornar o array original em vez de uma cópia.

/* parametros.java */
 
public class Parametros {
 
	private native int soma(int a, int b);
	private native String texto(String prompt);
	private native int[] somaArrays(int[] A, int[] B);
 
	public static void main(String[] args) {
		Parametros parametros = new Parametros();
		System.out.println("4+6=" + parametros.soma(4, 6));
		String string = parametros.texto("Digite algum texto");
		System.out.println("O texto digitado foi:" + string);
		int[] A = { 1, 2, 3 };
		int[] B = { 4, 5, 6 };
		int[] C = parametros.somaArrays(A, B);
		if (C == null) {
			System.out.println("Não foi possível realizar a soma.");
		} else {
			System.out.println("O resultado da soma dos arrays é:");
			for (int i = 0; i < C.length; i++) {
				System.out.println(C[i] + " ");
			}
			System.out.println();
		}
	}
 
	static {
		System.loadLibrary("parametros");
	}
}
 

Listagem 13: Código da classe Parametros.java

Implementação em C.

/* parametros.cpp */
 
JNIEXPORT jintArray JNICALL Java_Parametros_somaArrays(JNIEnv* env,
       jobject obj, jintArray arrayA, jintArray arrayB){
 
	jintArray arrayC;
	jint* A;
	jint* B;
	jint* C;
	jsize i;
	//Pegamos o tamanho de um dos arrays e comparamos
	jsize tamanho = (*env)->GetArrayLength(env,ArrayA);
	if(tamanho!=(*env)->GetArrayLength(env,arrayB))
		return NULL; //tamanho dos arrays são diferentes.
 
	//criação do array de retorno
	arrayC = (*env)->NewIntArray(env, tamanho);
 
	A = (jint*)(*env)->GetPrimitiveArrayCritical(env, arrayA, NULL);
	B = (jint*)(*env)->GetPrimitiveArrayCritical(env, arrayB, NULL);
	A = (jint*)(*env)->GetPrimitiveArrayCritical(env, arrayC, NULL);
 
	for (i=0; i < tamanho; i++)
		C[i] = A[i]+B[i];
 
	(*env)->ReleasePrimitiveArrayCritical(env, ArrayA,A, JNI_ABORT);
	(*env)->ReleasePrimitiveArrayCritical(env, ArrayB,B, JNI_ABORT);
	(*env)->ReleasePrimitiveArrayCritical(env, ArrayA,A, 0);
 
	return C;
}
 

Listagem 14: Código nativo parametros.cpp

Por ultimo devo dizer que JNI garante o acesso concorrente ao array por várias threads, uma vez que o JNI mantém um controlador de pinnings, para que uma thread não finalize o pinning de um array que outra thread esta usando.

Desempenho ao acessar os membros de um objeto

Para obtermos o fieldID ou o methodID realizamos uma busca simbólica em uma base de nomes dos membros, o que é relativamente custoso. Uma forma de diminuir este custo quando houver necessidade de se busca-los mais de uma vez é cachear-los.

Para cachear podemos usar duas técnicas:

1.Cachear em variáveis estáticas de uma função nativa, como por exemplo a função abaixo:

JNIEXPORT void JNICALL Java_MyClass_accessField(JNIEnv *env, jobject obj){
 
		static jfieldID fid_s = NULL; /* cacheando field ID para s */
		jclass cls = (*env)->GetObjectClass(env, obj);
		jstring jstr;
		const char *str;
		if (fid_s == NULL) {
			fid_s = (*env)->GetFieldID(env, cls, "s","Ljava/lang/String;");
			if (fid_s == NULL) {
				return;
			}
		}
		printf("Aplicação em C:\n");
		jstr = (*env)->GetObjectField(env, obj, fid_s);
		str = (*env)->GetStringUTFChars(env, jstr, NULL);
		if (str == NULL) {
			return;
		}
		printf(" c.s = \"%s\"\n", str);
		(*env)->ReleaseStringUTFChars(env, jstr, str);
		jstr = (*env)->NewStringUTF(env, "123");
		if (jstr == NULL) {
			return;
		}
		(*env)->SetObjectField(env, obj, fid_s, jstr);
}

Listagem 15: Código nativo para cache em variáveis estáticas

2.Cachear ao inicializar uma classe, isso quer dizer que em um bloco estático podemos chamar uma função que inicializa todos os atributos e métodos que vamos precisar.

public class MyClass {
 
	private static native void initIDs();
	private native void nativeMethod();
 
	private void callback(){
		System.out.println("Aplicação Java");
	}
 
	public static void main(String[] args) {
		MyClass call = new MyClass();
		call.nativeMethod();
	}
 
	static{
		System.loadLibrary("myclass");
		initIDs();
	}
}
 

Listagem 16: Código da classe MyClass, cache ao inicializar a classe.

Implementação em C.

jmethodID MID_MyClass_callback;
 
JNIEXPORT void JNICALL Java_MyClass_initIDs(JNIEnv *env, jclass cls){
	MID_ MyClass_callback = (*env)->GetMethodID(env, cls, "callback", "()V");
}
 
JNIEXPORT void JNICALL Java_ MyClass_nativeMethod(JNIEnv *env, jobject obj){
	printf("Aplicação C\n");
	(*env)->CallVoidMethod(env, obj,MID_MyClass_callback);
}
 

Listagem 17: Código nativo que implementa o cache na inicialização da classe

E logo initIDs() guarda os IDs em variáveis globais.
Das duas técnicas a mais recomendada é a segunda por varias razões:

1.Os IDs se tornam inválidos logo que a classe é descarregada. Conforme o class loader descarrega a classe e ao se carregar a classe não se atualizam os IDs, na primeira solução porem o mesmo não acontece.

2.É relativamente mais rápido uma vez que carregados os IDs não teremos que voltar a comprovar o valor do ID com:

if (fid_s == NULL) {}

Diferenças de custo entre os objetos nativos e os métodos Java

Neste tópico vamos comentar rapidamente qual o custo de se realizar uma chamada Java-nativo, nativo-Java (chamada callback), comparado com uma chamada java-java.

Uma chamada Java-nativo é mais lenta que uma chamada java-java porque:

1.A máquina virtual tem que liberar as referências locais pra depois chamar o método nativo.
2.A máquina virtual tem que buscar uma função dinâmica em sua biblioteca.
3.A máquina virtual muitas vezes pode chamar in-line quando um método Java chama outro método Java.

Estima-se que o custo é de duas a três vezes superior ao de uma chamada java-java.
Estima-se também que o custo de uma chamada nativo-Java (callback) é duas ou três vezes superior a uma chamada Java-Java. O principal custo agregado esta em:

1.Obtenção do fieldID e do methodID
2.E no acesso aos atributos através de funções, enquanto que a virtual machine pode acessá-los diretamente.

Para Saber Mais
Indicado pela Sun como fonte definitiva de informações sobre JNI.
LIANG, Sheng. The Java Native Interface - Programmers Guide and Specification.
Massachusetts: ADDISON-WESLEY, 1999. ISBN 0-201-32577-2.
Pode ser baixado em:
http://java.sun.com/docs/books/jni/download/jni.pdf

Considerações Finais

Neste artigo apresentamos uma visão geral de como se escrever aplicações híbridas envolvendo Java, JNI e bibliotecas dinâmicas nativas criadas a partir de código C. Abordamos algumas técnicas que podem ser utilizadas para facilitar a integração de sistemas legados. E, ainda uma breve visão de custo e melhoria de desempenho.

Como podemos perceber o JNI é uma ferramenta poderosa, contudo, é preciso estar ciente que uma aplicação Java chamando código nativo compromete a portabilidade e a segurança da aplicação. Pois, embora o bytecode Java compilado permaneça altamente portável, o código nativo deve ser recompilado para cada plataforma na qual se pretenda executar a aplicação.

Referencias

LIANG, Sheng. The Java Native Interface - Programmers Guide and Specification.
Massachusetts: ADDISON-WESLEY, 1999. ISBN 0-201-32577-2.

LINDHOLM, Tim;YELLIN, Frank. Java The JavaTM Virtual Machine Specification.
1999. Ultimo acesso em 17 de Julho de 2006. Disponível em:
< http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html>

MEAD, Matthew. Programmming in C/C++ with the Java Native Interface.
1998. Ultimo acesso em 17 de Julho de 2006. Disponível em:
< http://www.pacifier.com/~mmead/jni/cs510jip/index.html >.

SUN MICROSYSTEMS. Java Native Interface Specification.
2003. Ultimo acesso em 17 de Julho de 2006. Disponível em:

SUN MICROSYSTEMS. javap - The Java Class File Disassembler.
2002. Ultimo acesso em 17 de Julho de 2006. Disponível em:
< http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javap.html>

SUN MICROSYSTEMS. javah - C Header and Stub File Generator.
2002. Ultimo acesso em 17 de Julho de 2006. Disponível em:
< http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javah.html>

Com JNI alem de podermos acessar os atributos de um objeto Java podemos também acessar seus métodos, este acesso é conhecido como callback, pois o Java executa um método nativo e em seguida o método nativo executa um método Java.

Figura 2: Estrutura de Callback

Existem três tipos de métodos Java:
• Métodos de instancia
• Métodos de classe
• Construtores

Vamos abordar o procedimento a ser realizado em cada caso.

Acessando métodos de instancia

O acesso aos métodos de uma classe é extremamente parecido com o acesso aos atributos e para acessá-los também é preciso seguir dois passos:

1.O primeiro passo é obter o methodID do método usando a função:

GetStaticMethodID
Protótipo

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

2.E em seguida usamos as funções:

CallMethod
Protótipo:

<TipoNativo> Call<Tipo>Method(JNIEnv *env,jobject obj,
jmethodID methodID, ...);

Devemos usar a função de acordo com o tipo retornado. Os parâmetros são passados por uma lista de parâmetros variáveis que esta no final da função (...)

CallObjectMethod() é usado tanto para métodos que retornam objetos como para métodos que retornam arrays, para os métodos que retornam tipos primitivos devemos usar a função correspondente de acordo com a tabela acima.
Como exemplo, na listagem 7, faremos um método nativo chamado somaC() que chama um método Java chamado somaJava(), conforme listagem 6.

 
public class Contador {
	private int atributo = 0;
	private native void incrementa();
	private int somaJava(int a, int b){
		return a + b;
	}
	private native void somaC();
	public static void main(String[] args) {
		Contador contador = new Contador();
		System.out.println("Antes de chamar o método incrementa()
                  o atributo vale:"+contador.atributo);
		contador.incrementa();
		System.out.println("Depois de chamar o método incrementa()
                 o atributo vale:"+contador.atributo);
		contador.somaC();
	}
	static {
		System.loadLibrary("contador");
	}
}
 

Listagem 6: Contador.java, implementação do método somaJava()

E a implementação da função nativa correspondente:

 
/* contador.cpp */
 (...)
JNIEXPORT void JNICALL Java_Contador_somaC(JNIEnv *env, jobject obj){
	int a=5,b=4,c;
	//Obter o methodID
	jclass class = (*env)->FindClass(env,"Contador");
	jmethodID methodID = (*env)->GetMethodID(env, class, "somaJava", "(II)I");
	//Executando o metodo
	c=(*env)->CallIntMethod(env, obj, methodID, a,b);
	}
}

Listagem 7: Contador.cpp, implementação da função somaC()

Acessando métodos de classe

O processo é similar ao de execução de método de instancia, só que agora usamos outras funções.

1.Para obter o methodID usamos:
GetStaticMethodID
Protótipo:

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

2.Para executar os métodos usamos:
CallStaticMethodV
Protótipo:

<TipoNativo> CallStatic<Tipo>MethodV(JNIEnv *env, jclass clazz,
jmethodID methodID, va_list args);
 

Que são idênticas as executadas pelos métodos de instância, porem recebem como parâmetro um jclass em vez de um jobject.

Acessando métodos de instancia de uma superclasse

Em JNI podemos obter a classe base de uma classe usando:

Jclass GetSuperClass(HNIEnv* env, jclass class);

Esta função retorna uma classe ou NULL se a classe for um java.lang.Object ou uma interface.

Se executarmos um método que foi redefinido sobre uma referencia do tipo base usando as funções CallMethod() estaremos na verdade executando o método derivado, já que o Java usa ligação dinâmica.

Para executar um método de base teremos que usar as funções:

CallNonvirtualMethodV

Protótipo:

<NativeType> CallNonvirtual<Type>MethodV(JNIEnv *env, jobject obj, jclass clazz,
jmethodID methodID, va_list args);

Observe o exemplo das classes Java das listagens 8 e 9 e a implementação das funções nativas na listagem 10.

/* Base.java */
 
public class Base {
	public String  metodoJava() {
		return "Base";
	}
	public native void metodoC();
	public static void main(String[] args) {
		Base base = new Derivada();
		base.metodoC();
	}
	static{
		System.loadLibrary("Base");
	}
}

Listagem 8: Código da classe Base

/* Derivada.java */
public class Derivada extends Base{
	public String metodoJava(){
		return "Derivada";
	}
}

Listagem 9: Código da classe Derivada

Observe que metodoJava() foi redefinido. Vamos provar chamando o objeto do tipo Derivada, usando a função CallObjectMethod() e CallNonvirtualObjectMethod().

 
/* base.cpp */
 
(...)
JNIEXPORT void JNICALL Java_Base_metodoC(JNIEnv* env, jobject object){
 
	//Primeiro passo obter o methodID da classe Base
	jclass class = (*env)->FindClass(env,"Base");
	jmethodID methodID = (env*)->GetMethodID(env, class, "metodoJava","()Ljava/lang/String;");
	//Agora executamos o metodo sobre o object que é uma referencia do tipo Base
        //que aponta para um objeto Derivada e executa o metodo Derivada
	jstring mensagem=(jstring)(*env)->CallObjectMethod(env, object, methodID);
	const jbyte* mensagem_c = (*env)->GetStringUTFChars(env, mensagem, NULL);
	printf("A mensagem do metodoJava() é :%s", mensagem_c);
	(*env)->ReleaseStringUTFChars(env,mensagem, mensagem_c);
 
	//Agora vamos executar o método da Base
	mensagem = (jstring)(*env)->CallNonvirtualObjectMethod(env, object,class, methodID);
	mensagem_c = (*env)->GetStringUTFChars(env, mensagem, NULL);
	printf("A mensagem do metodoJava() é :%s", mensagem_c);
	(*env)->ReleaseStringUTFChars(env,mensagem, mensagem_c);
}

Listagem 10: Implementação da função nativa, que executa o método da classe Base

Obteremos como saída

A mensagem do metodoJava() é: Derivada
A mensagem do metodoJava() é: Base

Observe que é similar ao uso de super em Java, porem não é igual, pois em Java o super permite chamar os métodos de uma classe imediatamente da base, enquanto que com CallNonvirtualMethod() podemos executar os métodos de qualquer base.

Ex.: se temos:

Figura 3: Exemplo de hierarquia de classe

Tanto em JNI como em Java podemos chamar a partir de B os métodos de A, porem a partir de C não podemos executar os métodos de A usando super porem, podemos fazê-lo usando JNI.

Outra diferença é que podemos executar os métodos da classe base fora do objeto, coisa que não é possível fazer em Java usando super.

Resumindo em Java não podemos fazer:

A a = new B();
a.super.metodo();
 

Acessando um construtor

Acessar um construtor em JNI é igual ao acesso a qualquer outro método de instância a única diferença é que para acessarmos o construtor usamos “” como sendo o nome do método.
E uma vez que tenhamos o methodID do construtor podemos passa-lo para a função:
NewObject
Protótipo:

jobject NewObject(JNIEnv *env, jclass clazz,jmethodID methodID, ...);

Que instância o objeto e executa o construtor especificado.

Existe outra forma de criar objetos Java, que consiste em usar a seguinte função:

AllocObject
Protótipo:

jobject AllocObject(JNIEnv *env, jclass clazz);

Esta função cria um objeto sem iniciá-lo e em seguida usa-se uma função CallNovirtualMethod() para executar o construtor do objeto desejado.

Esta é uma forma menos elegante, pois obteríamos o objeto sem iniciá-lo e não poderíamos esquecer de chamar CallNovirtualMethod() e depois cria-lo com AllocObject().

Como exemplo na listagem 11, vamos fazer um método nativo que cria um objeto Ponto e o retorna com os valores passados como parâmetros ao método nativo.

/* Ponto.java */
 
public class Ponto {
	private int x;
	private int y;
	public Ponto(int x, int y) {
		this.x = x;
		this.y = y;
	}
	@Override
	public String toString() {
		return "["+x+","+y+"]";
	}
	public static native Ponto criaPonto1(int x, int y);
	public static native Ponto criaPonto2(int x, int y);
	public static void main(String[] args) {
		System.out.println(criaPonto1(2, 3));
		System.out.println(criaPonto2(1, 3));
	}
	static{
		System.loadLibrary("ponto");
	}
}
 

Listagem 11: Código da classe Ponto.java

Agora, na listagem 12, vamos implementá-lo com NewObject() e também com AllocObject().

/* ponto.cpp */
 
JNIEXPORT void JNICALL Java_PontocriaPonto1(JNIEnv* env, jclass class, jint x, jint y){
 
	jmethodID methodID = (env*)->GetMethodID(env, class,"<init>","(II)V");
	if(jmethodID==NULL)
		return NULL;
	return (*env)->NewObject(env,class,"<init>","(II)V");
 
}
 
JNIEXPORT void JNICALL Java_PontocriaPonto2(JNIEnv* env, jclass class, jint x, jint y){
	jobject obj;
 
	jmethodID methodID = (env*)->GetMethodID(env, class,"<init>","(II)V");
 
	if(jmethodID==NULL)
		return NULL;
	obj = (*en)->AllocObject(env,class);
	(*env)->CallNonvirtualVoidMethod(env,obj,class, methodID,x,y);
 
	return obj;
}
 

Listagem 12: Código nativo ponto.cpp

O Java suporta dois tipos de atributos:

• Atributos de instância, no qual existe um para cada objeto que instanciamos;
• Atributos de classe, cada classe possui uma única cópia do atributo, independente do número de objetos instanciados a partir da classe. Podemos distingui-los pelo modificador static.

Acessando atributos de instância
O acesso a atributos de instancia é muito simples porem é preciso seguir a risca dois passos:

1. O primeiro é obter o fieldID do atributo que queremos acessar, o fieldID é uma variável do tipo jfieldID usada pelo JNI para referenciar um atributo de um objeto. Para consegui-lo usamos a função:

GetFieldID
Protótipo:

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

2. Em seguida usamos uma função que nos permite pegar (get) o modificador do atributo a partir do seu jobject e seu fieldID.

GetField
Protótipo:

 GetField(JNIEnv *env,jobject obj,
jfieldID fieldID);

Como podem ver na tabela abaixo existe uma função GetField para cada tipo de dado.

Sendo que a primeira função da lista é para ler os atributos de objetos.
Existem também funções correspondentes para atribuirmos dados aos atributos (set):

SetField
Protótipo:

void Set<Tipo>Field(JNIEnv *env, jobject obj, jfieldID fieldID,
<TipoNativo> value);