Fala galera, vamos por parte como diria nosso amigo Jack…ehehehe
A aplicação hoje não possui reports, pois não é permitido (legislação) ter outra impressora que não seja a fiscal (ECF) conectada na estação.
Todos os relatórios são emitidos como texto puro direto na porta serial, então não cheguei a pensar nesse ponto.
Vi em um Livro que estou lendo [C++ GUI Programming with Qt 4] que a interface print é muito simples e exporta para HTML e XML, creio que isso seja o suficiente para relatórios, mesmo os mais complexos.
[quote=ViniGodoy]black_fire, você já rodou um profiler na sua aplicação para saber pq ela consome tanta memória?
Por que talvez a migração não compense o esforço extra. Ou talvez você esteja é presenciando um consumo devido à um bug, não ao Swing.[/quote]
Já fizemos uma análise que reduziu 200 Mb de memória, melhorando threads, e forçando o GC em alguns pontos, entre outros.
Agora o problema é o Hibernate, sem nada rodando (fora da aplicação) ele consome 150mb dos mapeamentos, tirar o hibernate hoje é quase escrever denovo, foi então que o C++ “veio a tona” como uma possibilidade muito forte.
Realmente não há mais o que fazer a não ser mudar alguns conceitos que hoje fazem parte da aplicação.
[quote=khaoz]Dado a realidade que ele apresentou, eu acreidto que a execução de um profiler e a correção de qualquer bug/memory leak encontrado, não vai fazer com que uma aplicação java/swing consuma uma quantidade de memória aceitável para determinado perfil de máquina.
Ainda não tive a oportunidade de usar um aplicativo swing que, depois de um certo tempo de uso, não estivesse com uma quantidade de memória exagerada para o tamanho e funcionalidade executada no momento.
E a realidade que se encontra em pdv’s por exemplo e complicada em muitos casos.
[]'s[/quote]
Pois é, fizemos um teste que foi simplesmente um absuro, dois formulários, um em Java e outro em QT. (Ambos limpos, sem nada)
Em QT o consumo ficou fixo 4Mb de memória, em Java, iniciou com 20 Mb e conforme a Janela é movida na tela chegou 30Mb, sem contar os picos de processamento.
Isso foi um tanto assustador… 
[quote=ViniGodoy]Onde ele apresentou a situação?
Mas realmente, fazer em C++ irá poupar bastante recursos. Só tem que tomar MUITO cuidado com as plataformas escolhidas, e também seguir direitinho os padrões, ou a aplicação não será portável.
black_fire, você precisa que ela rode em Linux também, ou só Windows?[/quote]
Isso é um ponto importante, hoje temos apenas Clientes em Linux, porém tem que ser 100% portável para o windows, pois é isso que vendemos hoje.
Quando iniciar o desenvolvimento faremos como hoje, sempre testando em ambos os ambientes sempre que há desenvolvimento novo.
[quote=ViniGodoy]Achei ali no blog onde ele descreve a situação.
Realmente, nem pelo Swing, mas pelo acesso direto a portas seriais e hardware, eu já desaconselharia o Java. A API javax.comm é praticamente abandonada, ainda na época da Sun (o suporte ao Windows, por exemplo, simplesmente sumiu). E a rxtx é boa, mas ainda deixa muito a desejar.
Usar C++ nesse caso é muito mais indicado. Não só vai te dar um controle maior da aplicação, como vai permitir que você rode em sistemas mais humildes.
Outra coisa, conside a possibilidade de seu PDV se comunicar via socket com um sistema de ponto de venda. Aí, somente o seu PDV fica em C++, enquanto o sistema em si continua em Java. A comunicação pode ser via socket, ou mesmo troca de arquivos (não sei como você faz isso hoje), mas não acho que valha a pena migrar as duas pontas do sistema.
Finalmente, não considero o Eclipse uma boa escolha de IDE. Ele é lento, tem pouca integração com o debugger. Se seu sistema for para Windows, sugiro que use o Visual C++. Se for multiplataforma, procure pelo Qt Develop.[/quote]
Pois é, nossa retaguarda hoje é Java Web, e continuará, será apenas o ponto de venda que será migrado, pois nesse caso as máquinas são melhores e não vale o esforço com certeza.
Comunicação com Libs em geral em Java é Fod… o problema é não dar exception, sempre que há um erro, simplesmente o Java fecha do nada, imprimindo um “log de erro muito amigável”.
Também achei meio complicado o debug do Eclipse, ainda não sei se será a escolha final se não tiver uma forma de melhorar o debug.
Abraço valeu pelas dicas…
Quanto ao javax.comm concordo. É uma pena uma api daquelas ter sido deixada no esquecimento, mas o rxtx considero uma ótima opção em comparação a outras (como a giovynet por exemplo), nesse caso gostaria de saber por que você acha que o rxtx deixa a desejar?
Já usou serial no C++?
Por incrível que pareça, é muito mais fácil que a RXTX. É mais fácil usar pinos em paralelo ou sincronizar dados.
Na verdade como disse no post anterior, não acho o problema exclusivo do RxTx, que funciona bem, o problema é a interação do Java com Lib (.so ou .dll).
Quando ocorre uma falha as libs não retornam erro para o Java, a VM simplesmente fecha.
O problema realmente não é o erro em si e sim a falta do motivo. Veja como exemplo, identificamos que no Debian, quando não há pariedade de memória (duas memórias de tamanho diferentes) eventualmente a VM fecha, quando as memórias são casadas corretamente isso não ocorre.
Em linguagens compiladas como C, C++ ou Pascal o acesso é mais natural e os tratamentos são melhores na minha opnião…
O duro são sempre os erros relacionados aos dangling pointers. Eles acabam abortando o programa sem muita informação também. Por isso é bem escolher um bom compilador, e ser muito, muito, muito, muito, muito, chato com alocação e desalocação de memória.
Não deixe de usar RAII e de seguir as dicas do Effective C++, ou você vai ter muitas dores de cabeças com erros sem qualquer tipo de informação.
Há um livro (um pouco antigo por sinal) chamado “J2EE Antipatterns”. Um dos antipatterns é “usar JNI”. Eles dizem que “use só quando não houver outra alternativa, e se possível segregar o código C/C++ em outro executável, e se comunicar com esse executável (por exemplo) via sockets ou arquivos.”
Já usou serial no C++?
Por incrível que pareça, é muito mais fácil que a RXTX. É mais fácil usar pinos em paralelo ou sincronizar dados.[/quote]
Ahh bom, quando você se referiu à deixar de desejar estava falando de facilidade de manuseio e manipulações mais apuradas (usar pinos em paralelo), tinha entendido que a critica estava ligada a fatores como perdas de dados e coisas como performance (que se considerarmos que estamos usando java e acessando uma lib c++ está dentro do aceitável), enfim coisas que até hoje não tinha observado.
[quote=black_fire]Fala ae pessoal, blz.
A muito tempo não passo por aqui, madar um super abraço para os velhos amigos…
Estou migrando uma aplicação de Java para C++, como sei que isso vai dar mais que um único post
resolvi criar um blog para isso…
Quem tiver interesse em acompanhar o andamento dessa migração, segue abaixo o link do blog:
Moderadores, minha intenção é apenas compartilhar o estudo.
Grande abraço a todos.[/quote]
Espero que tenhas uma boa razão para esta migração, porque senao podera ser esforço em vão e perda de performance e perda de portabilidade, e milhares de linhas de codigos a mais…
mas boa sorte, nao entendo porque que ainda tem pessoas que querem trocar um BMW X6 com um BMW X0
[quote=sulito]Espero que tenhas uma boa razão para esta migração, porque senao podera ser esforço em vão e perda de performance e perda de portabilidade, e milhares de linhas de codigos a mais…
mas boa sorte, nao entendo porque que ainda tem pessoas que querem trocar um BMW X6 com um BMW X0 [/quote]
As razões estão escritas no blog dele:
- Necessidade de controle fino sobre portas seriais;
- Necessidade de integração com recursos do SO;
- Necessidade de rodar em computadores bem modestos;
Nenhum dos três atributos são muito bem atendidos pelo Java.
Novo post incluído no blog,
.
Primeira Aplicação - Ferramenta SQL em QT
.
Abraço e obrigado a todos que estão acompanhando e comentando…
Novo post incluído no blog,
.
Detalhes da Programação ? Ferramenta SQL (Parte 1)
.
Abraço e obrigado a todos que estão acompanhando e comentando…
Novo post incluído no blog,
.
Detalhes da Programação ? Ferramenta SQL (Parte 2)
.
Abraço e obrigado a todos que estão acompanhando e comentando…
Novo post incluído no blog,
.
Detalhes da Programação - Ferramenta SQL (Parte 3)
.
Abraço e obrigado a todos que estão acompanhando e comentando…
Novo post incluído no blog,
.
Detalhes da Programação - Ferramenta SQL (Parte 4 - Final)
.
Abraço e obrigado a todos que estão acompanhando e comentando…
Novo post incluído no blog,
.
BigDecimal para C++
.
Abraço e obrigado a todos que estão acompanhando e comentando…
Deixei alguns comentários no seu blog, na página:
Espero que seja de alguma ajuda.
Boa sorte!
Nelson