Aplicação multiplataforma que faz chamadas nativas

Olá

Por partes, não necessariamente na ordem em que perguntou:

Sua aplicação precisará de um certificado digital de confiança (pode ser auto assinado caso seu cliente confie em você)

eclipso:

Estive fazendo uns testes aqui em ambiente windows e minha aplicação só funcionou se:
1-Setar o path com caminho da pasta em que o software nativo está instalado (para obter as bibliotecas de lá).
2-Copiar as bibliotecas desse software (da pasta em que ele está instalado) para a pasta System32 do windows…

Algumas questões:

1-Existe alguma alternativa fora essas que citei?
2-O que seria mais viável?
3-Tenho como setar o path do windows em tempo de execução do meu software Java?

Lembrando que preciso de uma solução que contemple a mesma situação em ambiente Linux…

Veja o tópico http://www.guj.com.br/posts/list/106972.java Atente para a observação do Thingol sobre qual C usar na compilação.

Para colocar a tal DLL no lugar que quer você precisara de uma outra applet assinada que faça a cópia da tal DLL do seu servidor para o diretório em que ela vai morar. É fácil fazer mas acho que isto aí lhe ajudará: http://www.javaworld.com/javatips/jw-javatip19.html

Se já tem isto, então está bom. Deixe de ser purista.

[]s
Luca

Primeiramente, obrigado pelas respostas e pela atenção dedicada ao meu problema…Fico realmente grato pela força, cara

Este meu software em questão já está auto-assinado…

Eu já havia implementado uma applet para fazer isso, mas meio que abandonei esta idéia de fazer download das bibliotecas nativas do meu servidor. Tive que fazer isso porque, no meu caso, era um tanto inviável, visto que eu sempre tinha que fazer o download de quase 35MB de bibliotecas…Optei por relacionar o tal software nativo (o VLC player) como um pré-requisito da minha aplicação…Ou seja, devo assumir que meu usuário instalou o VLC player antes de utilizar minha aplicação. Neste caso, todas as bibliotecas já estão armazenadas localmente na máquina cliente, a grande questão é fazer o Java “enxergar” essas bibliotecas. Segundo sua resposta, imagino que o mais viável seja, na primeira utilização da minha aplicação, a mesma fazer uma cópia das DLL’s necessárias da pasta de instalação do VLC player para um desses caminhos do path do Java (obtidos através de System.getProperty (“java.library.path”)). O que você acha? É comum este tipo de prática? E o mais importante, é uma boa prática?

É que era mais uma questão de saber se o pessoal não sabia de alguma alternativa mais inteligente/elegante/adequada. A idéia é sempre fazer uma aplicação 100%
No caso de assumir esta minha solução no software final, posso fazer algumas otimizações no processo, também. Por exemplo, posso exibir uma caixa de diálogo pedindo para o usuário se ele quer que a aplicação procure a pasta de instalação automaticamente ou se ele quer informar explicitamente a pasta de instalação…Depois de localizada a pasta na primeira execução do programa, posso gravar um arquivo em um dos diretórios que podem ser obtidos acessando as propriedades do sistema, de modo que sempre que meu softwae iniciar, faça uma busca antes neste arquivo…

Abraço…

E obrigado novamente

Olá

Não sei se é uma boa prática. Isto é um caso especial. Se for fácil de fazer, manda bala e bola pra frente.

Não faça, a solução automática que descreveu antes é melhor e menos sujeita a erros. E tenha sempre em mente a sigla YAGNI. Ver http://pt.wikipedia.org/wiki/YAGNI

[]s
Luca

Certo…

Pensei em uma outra alternativa agora, que não pressupõe a instalação do software nativo (VLC player) como pré-requisito:
Dividir minha aplicação em dois jar´s distintos…Um deles (1) é minha aplicação, responsável pela funcionalidade, o outro seria um jar que encapsularia as bibliotecas nativas necessárias e todo o mecanismo de manipulação dessas bibliotecas.
Numa distribuição da aplicação via JWS, o usuário clicaria no link da ferramenta, o jar 1 seria executado, se fosse a primeira execução baixaria o jar 2 para a pasta de extensão da lib do Java e a utilizaria, nas execuções subseqüentes, não precisaria mais baixar este jar 2…

Tem como fazer algo do gênero (utilização desses dois jar´s dessa forma)? Esse encapsulamento de bibliotecas nativas é viável (é provável que eu tenha que extrair essas bibliotecas a cada execução)?

Olá

eclipso:

Dividir minha aplicação em dois jar´s distintos…Um deles (1) é minha aplicação, responsável pela funcionalidade, o outro seria um jar que encapsularia as bibliotecas nativas necessárias e todo o mecanismo de manipulação dessas bibliotecas.
Numa distribuição da aplicação via JWS, o usuário clicaria no link da ferramenta, o jar 1 seria executado, se fosse a primeira execução baixaria o jar 2 para a pasta de extensão da lib do Java e a utilizaria, nas execuções subseqüentes, não precisaria mais baixar este jar 2…

Prefiro a solução mais simples de criar um programazinho de instalação, a ser rodado uma vez em cada PC, só para baixar as bibliotecas nativas. Foi assim que agi quando precisei usar periféricos acessados pelo javax.comm. As DLLs dos periféricos e o javax.comm foram instalados usando aquele conceito de baixar arquivo do servidor que citei antes.

[]s
Luca

Certo…Mas minha aplicação deve rodar em linux também…Neste caso, minha aplicação obteria as bibliotecas nativas do VLC para linux (so´s)…Mas não sei se não terei problemas de permissão para copiar essas bibliotecas para esses diretórios acessíveis pelo java.library.path…Alguém sabe algo a respeito…

É por isso que você tem de criar um instaladorzinho, já que você terá de usar o “sudo” para obter as permissões adequadas para copiar as bibliotecas.
De modo geral, no Unix/Linux, normalmente você não tem permissão para fazer nada, e você tem de sempre obter as permissões via “sudo”.

Para linux vc tem boas opções como gerar um pacote RPM ou DEB.

A instalação fica a cargo de um “yum install pacoteX” e a recuperação do servidor fica muito facil em caso de pane na maquina. Como quem instala geralmente o faz via sudo, vc nem precisa se preocupar com permissões, exceto no que diz respeito ao seu programa e as bibliotecas que vc precisa. E, se preferir, pode colocar algumas bibliotecas como pre-requisito do seu pacote. Fazer um RPM não é complicado, mas precisa de alguma atenção.

Agora, se vc vai fazer chamadas nativas a bibliotecas e essas podem ser diferentes de SO para SO, seria bom vc pensar numa “Anti Corruption Layer” na hora de fazer essa integração.

É por isso que você tem de criar um instaladorzinho, já que você terá de usar o “sudo” para obter as permissões adequadas para copiar as bibliotecas.
De modo geral, no Unix/Linux, normalmente você não tem permissão para fazer nada, e você tem de sempre obter as permissões via “sudo”.

Eu pensei em fazer essa instalação na primeira execução do software. Algo como o usuário clica no link JWS da aplicação, ela é baixada localmente, começa a executar, verifica se as bibliotecas nativas necessárias estão no diretório adequado, se não estiver, baixa as bibliotecas do meu servidor e as instala no diretório em questão e em seguida abre a interface principal, caso as bibliotecas estejam OK, abre a janela principal…

No windows isso funciona legal…Mas no Linux eu não sei como faria nesta abordagem. Embora isso não me pareça uma alternativa que transpire confiança e segurança para o usuário, teria como abrir uma janela pedindo usuário e senha?

De outra forma, como seria este instalador que você fala? Como funcionaria a dinâmica desse software?

Mas esses pacotes variam de distribuição para distribuição, não? Em relação à alternativa de criar um instalador, esta saída não se torna desnecessariamente mais complexa? De qualquer forma, você poderia me indicar referência para criar eses pacotes?

Você poderia me falar mais a respeito desta sua apreensão? Como seria esta “Anti Corruption Layer”?

Obrigado a todos…Agredeço pela atenção.

Alguém poderia me dar uma mão nisso?

Cara, vc pode pesquisar se um formato RPM, DEB servem para o seu caso. Se o ambiente não é padronizado vc tem muitas opções, como criar um shell script que instala tudo a partir de um tar.gz , etc.

Sobre o “Anti Corruption Layer”:
http://domaindrivendesign.org/practitioner_reports/peng_sam_2007_06.pdf

Pois é, minha ferramenta será acessível via portal, dentro de uma lógica “acesse de qualquer lugar e utilize as funcionalidades”…Assim, em tese, estaria lidando com um ambiente altamente heterogêneo…Em tese, porque estou me preocupando em fazer funcionar para Windows XP ou superior e a aior parte das distribuições Linux nas quais eu conseguir rodar…Mesmo assim, não é padronizado, só reduzo a heterogeneidade…
Nesta sua proposta, eu criaria um shell sript de instalação, faria o download desse tar.gz do meu servidor e em seguida executaria (via chamada nativa, imagino) esse scrip para extrair e instalar? Como trato o controle de permissões no shell script?

Desculpe qualquer bola na trave, colega…É que essa interação com o ambiente nativo é algo bastante novo pra mim…

Agradeço a atenção. As sugestões de vocês já expandiram consideravelmente meu entendimento do contexto todo…

Se mais alguém tiver sugestões, agradeço…