Jacbrframework: Via Jna

[vtbraun]

Amigos, boa tarde... Estou com um problema coloquei um procedimento na acbrframework32.dll compilada em lazarus, para que reconheça velocidade da impressora quando não é a padrão, 9600, mas qnd coloco para executar meu sistema, a "acbrframework_JNI.dll" da erro. O que tenho que fazer para que a dll reconheça impressora com velocidade, acima de 9600?

[Rafael Dias]

@vtbraun

 

A opção de selecionar velocidade ja esta implementada no acbrframework32.dll, não tem necessidade de modificações, você precisa apenas editar o acbrframework_jni.dll, para adicionar novas opçoes.

[vtbraun]

Qual a chamada então, no projeto em Java?

[Rafael Batiati]

@vtbraun

 

Por favor, dê uma lida do tópico abaixo, lá já discutimos algo sobre o JNI.

 

(...)

 

Nós recomendamos que antes de fazer qualquer alteração no ACBrFramework ou no jACBrFramework, traga aqui para o fórum sua necessidade e idéias, para que possamos discutir juntos a melhor solução e integrá-las ao SVN do projeto.

 

O jACBrFramework tem muito o que evoluir, atualmente não temos nem 50% do ECF implementado em java, enquanto no projeto ACBrFramework.Net em C# já tem dezenas de componentes completamente implementados e funcionais, entre o ECF, AAC, EAD, PAF, RFD, Sped, Sintegra, Balança, LCB, IBGE, Validador, etc.

 

A evolução do projeto só depende da união dos esforços dos usuários e colaboradores interessados.

Estamos a disposição.

 

Abs!

[vtbraun]

Essa questão de setar a velocidade da impressora, assim como já é feito com a porta da impressora, já existe?

[Rafael Batiati]

Essa questão de setar a velocidade da impressora, assim como já é feito com a porta da impressora, já existe?

 

Sim, no projeto ACBrFramework em Delphi, já existem as funções da DLL expostas para manipular os parâmetros da serial, basta implementar o JNI (C++) dela e depois as chamadas nativas em Java.

 

Nosso objetivo é manter o jACBrFramework com uma API o mais parecido o possível com os componentes ACBr escritos em Delphi. Dessa forma nós podemos aproveitar do fórum os exemplos, soluções de dúvidas e formas de uso. Pra fazer isso, precisamos analisar como é o componente original no Delphi e escrever a classe Interop em JNI e Java para ele.

 

Todas as operações que manipulam a porta serial são tratadas pela classe Device (no Delphi), que contém Porta, Bauds, Paridade, StopBits, etc, etc. No .Net nós implementamos essa classe "Device" com as mesmas capacidades e características, tal como no Delphi ela permite trabalhar com qualquer outro componente que use a Serial, como o ECF, a Balança, Leitor de código de barras, etc. A nossa idéia é implementar em Java seguindo o mesmo design.

 

Aquele post que eu te passei antes contém alguma discussão sobre a implementação no JNI (projeto em C++) e no Java; Coisas indispensáveis no nosso caso.

Caso você tenha interesse em desenvolver, posso ajudá-lo nisso.

 

Abs,

[vtbraun]

Tenho interesse sim

 

Sim, no projeto ACBrFramework em Delphi, já existem as funções da DLL expostas para manipular os parâmetros da serial, basta implementar o JNI (C++) dela e depois as chamadas nativas em Java.

 

Nosso objetivo é manter o jACBrFramework com uma API o mais parecido o possível com os componentes ACBr escritos em Delphi. Dessa forma nós podemos aproveitar do fórum os exemplos, soluções de dúvidas e formas de uso. Pra fazer isso, precisamos analisar como é o componente original no Delphi e escrever a classe Interop em JNI e Java para ele.

 

Todas as operações que manipulam a porta serial são tratadas pela classe Device (no Delphi), que contém Porta, Bauds, Paridade, StopBits, etc, etc. No .Net nós implementamos essa classe "Device" com as mesmas capacidades e características, tal como no Delphi ela permite trabalhar com qualquer outro componente que use a Serial, como o ECF, a Balança, Leitor de código de barras, etc. A nossa idéia é implementar em Java seguindo o mesmo design.

 

Aquele post que eu te passei antes contém alguma discussão sobre a implementação no JNI (projeto em C++) e no Java; Coisas indispensáveis no nosso caso.

Caso você tenha interesse em desenvolver, posso ajudá-lo nisso.

 

Abs,

Tenho interesse sim, vamos colocar para frente também o jAcbrFramework...

[Rafael Batiati]

Excelente então.

 

Baixe o código fonte pelo SVN (http://acbrframework.sourceforge.net/downloads/codigo-fonte/), e prepare seu ambiente, vai precisar do Visual Studio com C++ (pode ser o express), e se você tiver algum conhecimento em C# será bom para se basear em algumas soluções que já tivemos no .Net.

 

Você já tem alguma familiaridade com o desenvolvimento em C/C++, e com JNI ? Se sim será excelente, mas nada que não possa aprender com um pouco de pesquisa, é muito simples.

 

A primeira coisa a fazer é entender como funciona esse mecanismo, e identificar as funções que você precisa no ACBrFramework e implementá-las no JNI. Depois, como o outro post ilustra, é só fazer a "casca" em java, com as chamadas "native".

 

Dá uma estudada, e posta as dúvidas aí pra gente.

Qualquer fonte modificado pode atachar aqui no post também.

Abs

[vtbraun]

Já estou trabalhando em cima, acrescentando alguma coisas no jAcbrFramework.

[Rafael Batiati]

Pessoal,

Visando facilitar a vida dos novos colaboradores que estão entrando no projeto jACBrFramework, nós demos uma arrumada na casa.

Temos algumas novidades no jACBrFramework e jACBrFramework_JNI:

 

 

Refactory das classes bases do projeto (criação de ACBrInteropBase, ACBrClass e ACBrComposedClass)

Agora a estrutura das classes em java estão mais parecidas com design usado nas classes do .Net;

Isso nos leva a aplicar as mesmas soluções usadas no .Net para resolver os vários cenários de Interop com os objetos do ACBr.

 

Criação da classe Device e inclusão da propriedade Device no ACBrECF

Já usando a nova classe base ACBrComposedClass, a classe Device foi criada.

Ela manipula as propriedades da comunicação serial.

Agora é possível fazer algo assim:

 

ACBrECF ecf = new ACBrECF();
ecf.getDevice().setPorta("COM1");
ecf.getDevice().setBaud(115200);

 

Incluímos a título de exemplo apenas as propriedades getPorta/setPorta e getBaud/setBaud; As demais bastam ser adicionadas seguindo o mesmo modelo.

 

Criação do projeto no NetBeans (descontinuado o projeto no Eclipse)

O antigo projeto em Eclipse foi migrado para o NetBeans, por ser mais popular e mais fácil de usar.

Em breve vamos migrar o projeto do JNI do Visual C++ para o NetBeans também.

 

Atualização das libs e dos headers do ACBrFramework no projeto ACBrFramework_JNI

Atualizamos o JNI para usar a última versão do ACBrFramework.

Isso nos dá acesso às últimas correções/melhorias.

 

(...)

 

Planos para o futuro próximo:

 

- Adicionar o suporte aos eventos do ACBr utilizando Listenners no java. Fundamental para implementar componentes orientados a eventos como o TEFD por exemplo;

- Automatizar o processo de criação das libs e headers utilizados no ACBrFramework_JNI, para que tenhamos mais agilidade na hora de atualizar correções/modificações feitas;

 

 

(...)

 

Baixem o código pelo SVN e confiram.

 

Qualquer dúvida sobre uso, ou desenvolvimento no java ou JNI é só postar aqui.

E lembrando, para mantermos a compatibilidade das alterações feitas por todos os colaboradores, é fundamental que a participação no forum e o envio dos fontes alterados.

 

Abraços!

[vtbraun]

Show de Bola, to trabalhando em cima agora do TEF... Agora, quando vou abrir o projeto do AcbrFramework_JNI depois de ter feito update no svn está abrindo como ACBR32_JNI...

[Rafael Batiati]

Cara, o funcionamento do TEFD é todo baseado em eventos, e ele precisa do ECF pra funcionar também.

Eu sugiro finalizar o ECF primeiro pra depois pegarmos o TEFD com mais proveito.

 

(...)

 

Quanto ao projeto do SVN, você está baixando o código do lugar certo mesmo?

a versão commitada do SVN chama-se ACBrFramework_JNI e jACBrFramework.

https://acbr.svn.sourceforge.net/svnroot/acbr/ACBrFramework/jACBrFramework

[vtbraun]

Ok, concordo.

 

Agora deixa lhe fazer uma pergunta, porque não usamos no java, a chamada direta do AcbrFramework32.dll? Ao inves de ser JNI, ser JNA. Como é feita a darumaframewrk

[Rafael Batiati]

Concorco 100% que implementar o JNI é um trabalhão.

Mas precisamos dele porque o java não suporta chamar um método nativo diretamente, só através do JNI ou do JNA**.

 

O que acontece com a darumaframework, é que na mesma DLL eles implementam tanto as chamadas nativas quanto as chamadas de JNI, sem precisar de 2 dlls.

 

Pra fazermos o mesmo que a Daruma faz no ACBrFramework32.dll, precisaríamos fazer o JNI em Pascal. Não que seja impossível, mas vai depender de projetos de terceiros, pois a Sun/Oracle só suporta C/C++ 

 

**Outra saída que temos é usar o JNA ao invés do JNI. Isso dispensa o projeto em C++ e tornaria o código Java responsável pelas chamadas, da mesma forma como o .Net é hoje.

A desvantagem do JNA é depender de pacotes específicos para isso. Como eu não trabalho diretamente com java não sei até onde seria exatamente um problema na prática.

 

http://today.java.net/article/2009/11/11/simplify-native-code-access-jna

 

 

Qualquer idéia pra facilitar/melhorar é bem vinda.

Abs!

[Rafael Batiati]

Acrescentando algo mais:

 

Veja o projeto abaixo

https://code.google.com/p/jnaerator/

 

Ele pode criar as interfaces JNA a partir dos headers C++ que já temos no JNI.

Se der certo, é um bom caminho ... topa modificar os javas pra usar JNA ???

 

Abs!

[vtbraun]

Acho uma excelente ideia. Topo

[Rafael Batiati]

Legal, vou fazer uns testes e ver se dá certo.

 

Só vejo um problema nisso: os eventos.

Os eventos são implementados como ponteiros de função chamados a partir do Delphi, é um callback na verdade. Provavelmente nem via JNI nem via JNA daria pra fazer isso. A única solução que eu vejo no momento é implementando o ponteiro de função no C++ e chamando o método em Java via JNI no momento que o callback rodar.

 

Talvez usar o JNA e implementar apenas os eventos em JNI seja uma solução, não sei.

(*EDITADO, é possível sim Callback pelo JNI, conforme post mais abaixo)

 

 

Como a DLL nativa ACBrFramework32.dll não foi idealizada para ser usada diretamente, é preciso criar também os modelos de classes para dar sentido a API do ACBr.

 

Por exemplo, faz muito mais sentido fazer assim:

ACBrECF ecf = new ACBrECF()
ecf.getDevice().setPorta("COM1");

 

Do que fazer assim:

 

int handle = ACBrFramework.ECF_Create();
int ret = ACBrFramework.Device_SetPorta(handle, "COM1");

if (ret != 0)
{
  throw new Exeception("Erro...");
}

 

 

 

As classes ACBrECF e Device são na verdade "wrappers" para colocar sentido nas funções da DLL nativa.

Ficaria algo assim, usando JNA:

 

public void setPorta(string porta)
{
   int ret = ACBrFramework.Device_SetPorta(porta);
   checkResult(ret);
}

 

 

 

 

Nesse ponto (opinião minha), o trabalho de implementar as chamadas da Library JNA para as classes Java é bem equivalente a implementar em C++ e apenas declarar o método native na classe. Só muda o local, em um você faz em C++ no outro faz em Java.

No Java com JNA é o código acima, e no C++ com JNI o código abaixo:

 

JNIEXPORT void JNICALL Java_jACBrFramework_ACBrDevice_setPorta(JNIEnv *env, jobject obj, jstring porta)
{
	SetString(&DEV_SetPorta, env, obj, porta);
}

 

 

Mas claro que temos que levar outras coisas em conta, como facilidade no entendimento e manutenção do projeto.

Vamos nos falando.

Abs,

[vtbraun]

Ta faltando o JAcbrDevice.cpp, quando abro o AcbrFramework_JNI, no VS.

[Rafael Batiati]

Ta faltando o JAcbrDevice.cpp, quando abro o AcbrFramework_JNI, no VS.

 

Falha nostra, pode atualizar pelo SVN.

[Rafael Batiati]

Nossos problemas acabaram-se!!

 

É possível fazer chamadas de callback nativo via JNA,

http://stackoverflow.com/questions/11849595/how-to-use-jna-callback

 

Então podemos esquecer o blá blá blá do post anterior, acho que vai dar certo sim.

Começarei um trecho experimental como prova de conceito, dando certo eu posto aqui.

 

Abs!

[vtbraun]

Dando certo. Vai ficar muito melhor, näo acha? Estou terminando de implementar os outros metodos do device no AcbrFramework_JNI

[Rafael Batiati]

Pessoal,

Fiz um commit inicial do jACBrFramework usando o JNA ao invés do JNI.

 

A classe Device foi toda implementada como modelo, mas no ACBrECF nem todos os métodos funcionam ainda, os métodos ainda declarados como "native" deverão ser substituídos pelos métodos que chamam o JNA.

 

Acrescentei ao projeto as classes de interop com a DLL Nativa ACBrFramework32.dll.

Elas contém TODAS as funções já implementadas no ACBrFramework32.dll, e foram feitas a partir dos arquivos de include .h usando o *JNAerator*, mas planejo adaptar o nosso DefExporter que já gera as declarações em C/C++ e VB6 para gerar em Java também.

 

Há também a pasta \lib contendo os jars necessários para usar o jna, esses precisarão ser distribuídos juntos do jACBrFramework.

 

(...)

 

Essa é uma boa hora de revisar e inserir coisas que faltam no ACBrECF do jACBrFramework.

O programa de exemplo teve um trecho comentado em decorrência disso, pois ainda falta implementar vários métodos.

 

Em suma, tem menos coisas funcionando agora que antes com o JNI, mas em compensação temos o modelo de como fazer mais fácil.

Esse commit é mais para partilharmos o progresso feito até agora e pensarmos juntos no que vai ser daqui pra frente. Pelo visto o projeto JNI será descontinuado e é bom focarmos os esforços nesse novo modelo.

 

(...)

 

Para os interessados em rodar o código, eu só consegui fazer funcionar colocando a ACBrFramework32.dll no Windows\System32 ou no Windows\SysWOW64 para Windows 64bits.

Certamente tem como distribuir a dll junto dos jars, mas como não tive tempo ainda de pesquisar sobre isso, usei ela no path do windows mesmo.

Atenção para incluir os .jars do JNA ao classpath e no caso de Windows 64its, executar numa JRE de 32bits para ser compatível com a DLL de 32bits.

 

Abraços

[vtbraun]

Então não sera mais necessário a dll, AcbrFramework_Jni?

[Rafael Batiati]

Fazendo com JNA não seria mais necessário a dll ACBrFramework_JNI.

Estou em vias de terminar o piloto dessas alterações, mas pelos testes que fiz acho que será a melhor solução.

 

Assim que tiver novidades eu posto aqui.

Abs,

[Rafael Batiati]

Pessoal,

Boas novidades.

 

O projeto jACBrFramework passou por um grande refactoring, novas classes bases e reorganização dos pacotes.

 

A classe ACBrECF (que agora fica no pacote jACBrFramework.serial.ecf.ACBrECF) está com todas as propriedade e métodos implementados.

Só faltam alguns ajustes nos métodos que retornam/recebem classes complexas.

 

Temos também suporte a eventos agora no Java (via Listeners), por enquanto apenas poucos eventos foram adicionados para fins de teste.

Todos os eventos foram adicionados ao componente ACBrECF, veja no exemplo como utilizá-los.

 

O ECF está bem mais completo que a versão anterior, e mais simples de manter.

Com essas alterações novos componentes poderão ser adicionados mais facilmente, dispensando o uso de C++ para as chamadas nativas.

Baixem os fontes e confiram.

 

Qualquer dúvida/problema é só postar por aqui.

Abs