System.load - ora funciona, ora não funciona

Tenho um jar que contém um shared objects(libjcoruja.so), no pc que estou desenvolvendo ele costuma funcionar bem, mas as vezes fica tentanto carregar por um bom tempo, porém não consegue. Tentando, de repente, ele consegue carregar rapidamente, em menos de 1 segundo. Quando vou testar em outros computadores, ele fica só tento carregar e nunca termina.

Detalhando mais um pouco, eu faço a extração em tempo de execução do libjcoruja.so para o diretório “/home/10080000701/.libreoffice/3/user/uno_packages/cache/uno_packages/J5eXDD_/SpeechOO.oxt/jlapsapiLibPath”

minha mensagem de controle é essa no terminal

*jlapsapi direto libLoader: “/home/10080000701/.libreoffice/3/user/uno_packages/cache/uno_packages/J5eXDD_/SpeechOO.oxt/jlapsapiLibPath/libjcoruja.so” loading, o que está entre aspas é o caminho absoluto da .so.

public static void loadLib(String oxtRoot){ //libname() retorna libjcoruja.so System.out.println("*jlapsapi libLoader: "+oxtRoot + "/" + libName()+" ); System.load(oxtRoot + "/" + libName()); }

Como vocês podem ver, o caminho está absolutamente certo porque eu copio o que foi impresso e mando copiar o arquivo para um outro diretório e tudo ocorre perfeitamente. E os arquivos com certeza são extraídos corretamente.

Contudo ele fica nesse história de não carregar.

O que acho que pode ser?

Utilizo esses pacotes para fazer a extração dos dados

import java.util.zip.ZipEntry; import java.util.zip.ZipException; import java.util.zip.ZipFile;

Existe alguma possibilidade disso executar como um thread e, na hora que o sistema tentar carregar a .so, ela ainda estar sendo extraída pelo código Java? eu não crio uma thread pra fazer isso como o código mostra

[code]
package br.ufpa.laps.jlapsapi.util;

import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.URI;
import java.net.URISyntaxException;
import java.net.URL;
import java.security.CodeSource;
import java.security.ProtectionDomain;
import java.util.Enumeration;
import java.util.zip.ZipEntry;
import java.util.zip.ZipException;
import java.util.zip.ZipFile;

//Extract files directly from inside jlapsapi.jar

public class ZipExtractor {

@SuppressWarnings("unchecked")
public static void extrairZip( File arquivoZip, File diretorio ) throws ZipException, IOException {  
	ZipFile zip = null;
	File arquivo = null;
	InputStream is = null;
	OutputStream os = null;
	byte[] buffer = new byte[2048];
	try {

		if( !diretorio.exists() ) { 
			diretorio.mkdirs();
		}
		if( !diretorio.exists() || !diretorio.isDirectory() ) {
			throw new IOException("Diretório inválido");
		}
		zip = new ZipFile( arquivoZip );
		Enumeration e = zip.entries();
		while( e.hasMoreElements() ) {
			ZipEntry entrada = (ZipEntry) e.nextElement();
			if(entrada.getName().startsWith("gramtools/") || entrada.getName().startsWith("jlapsapiLibPath/")){
				arquivo = new File( diretorio, entrada.getName() );
				//se for diretório inexistente, cria a estrutura   
				//e pula pra próxima entrada  
				if( entrada.isDirectory() && !arquivo.exists() ) {
					arquivo.mkdirs();
					continue;
				}
				//se a estrutura de diretórios não existe, cria  
				if( !arquivo.getParentFile().exists() ) {  
					arquivo.getParentFile().mkdirs();  
				}  
				try {  
					//lê o arquivo do zip e grava em disco  
					is = zip.getInputStream( entrada );  
					os = new FileOutputStream( arquivo );  
					int bytesLidos = 0;  
					if( is == null ) {  
						throw new ZipException("Erro ao ler a entrada do zip: "+entrada.getName());  
					}  
					while( (bytesLidos = is.read( buffer )) > 0 ) {  
						os.write( buffer, 0, bytesLidos );  
					}  
				} finally {  
					if( is != null ) {  
						try {  
							is.close();  
						} catch( Exception ex ) {}  
					}  
					if( os != null ) {  
						try {  
							os.close();  
						} catch( Exception ex ) {}  
					}  
				} 
			}
		}  
	} finally {  
		if( zip != null ) {  
			try {  
				zip.close();  
			} catch( Exception e ) {}  
		}  
	}  
}	

public static URI getJarURI() throws URISyntaxException {
	final ProtectionDomain domain;
	final CodeSource source;
	final URL url;
	final URI uri;

	domain = MkdfaRunner.class.getProtectionDomain();
	source = domain.getCodeSource();
	url = source.getLocation();
	uri = url.toURI();

	return (uri);
}

}[/code]

Acho que cheguei mais perto do que realmente é o problema.

Descobri que a exceção UnsatisfiedLinkError está sendo lançada(System.Load() não obriga tratar exceção, coloquei os catchs porque na documentação dizia que tratava, mas não era cobrado usar como normalmente os métodos cobram, isso é estranho). A mensagem é:

/home.local/localuser/.libreoffice/3/user/uno_packages/cache/uno_packages/aaueiN_/SpeechOO.oxt/jlapsapiLibPath/libjcoruja.so: libcoruja.so: cannot open shared object file: No such file or directory

Agora vamos por partes

libjcoruja e libcoruja estão no mesmo diretório. Usando o mesmo computador, porém logado com contas diferentes não funciona no localuser, mas na minha conta sim. Os “path” do java são exatamente os mesmos.

lembrando que o diretório está absolutamente correto.

Eu preciso carregar somente a libjcoruja, uso o comando:

System.load("/home.local/localuser/.libreoffice/3/user/uno_packages/cache/uno_packages/aaueiN_/SpeechOO.oxt/jlapsapiLibPath/libjcoruja.so");

libjcoruja faz a comunicação do código em java com o C++, ou seja, estou usando JNI.

A aplicação que estou fazendo necessariamente precisa que eu não use poderes de superusuário para salvar a libjcoruja e libcoruja, tenho que fazer elas serem carregadas de um diretório qualquer. Testando, eu já pus as duas libs no /usr/lib/, lá funciona perfeitamente e em qualquer computador. Mas quando deixo em um diretório qualquer, só funciona na minha conta, sendo que todos os diretórios são carregados pelo caminho absoluto.

Acho que tem alguma coisa a ver com configuração de um dos PATHs do java.

Já tentei em tempo de execução acrescentar o diretório das libs no System.getProperty(“java.library.path”)[Library path] , porém ele não conseguiu achar o libjcoruja, se eu atualizar o LD_LIBRARY_PATH com o caminho das libs, e por a aplicação para executar, ele funciona normal também.

Outra chance, li alguma coisa sobre o Windows que, às vezes, um dll que precisa de outra dll tem dificuldades utilizar a segunda, talvez eu esteja passando pela mesma coisa.

Uma solução seria eu conseguir salvar essas libs em um diretório que library path padrão do JAVA já procure sem que eu precise por o usuário final do app para atualizar a variavel de ambiente no computador dele.