laudenpower wrote: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?

khaoz wrote:Uma pequena dúvida, já que você esta desenvolvendo esse tipo de aplicativo: Qual ferramenta utilizará para relatórios ? Acredito que hoje use ireport/jasperreport. Prentende manter a dupla ou existe uma solução do nível e em c++ ?[]'s

ViniGodoy wrote: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.

khaoz wrote: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

ViniGodoy wrote: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?

ViniGodoy wrote: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.

entanglement wrote:Plugins? Eu aconselharia apenas segregar e encapsular a funcionalidade dependente de sistema operacional em algumas classes, não precisa complicar seu código mais ainda ao carregar plugins dinamicamente. Não é isso que vai deixar sua aplicação "portável".
Se olhar os fontes do JDK que estão em C++ vai ver que há uma boa parte comum e há algumas partes que são segregadas e diferentes. Baixe os fontes do JDK em:
http://download.java.net/jdk6/source/

entanglement wrote:Eu digo que uma aplicação desktop que tiver mais de 1 janela ou 3 controles deve usar algum toolkit.
Ou seja, quase todas.
Os casos de uso em que se necessita codificar tais aplicações na mão são muito poucos e específicos.
E use o Qt; além disso, investigue o Boost. No começo você vai apanhar bastante (aff) mas depois vai ver que é bastante fácil portar algo de Java para C++ / Boost porque os conceitos ficam bem parecidos. Vou dar um exemplo daqui a pouco.

lavh wrote:...vc vai migrar uma big aplicação para C++, e só tem 2 semanas de estudo de C++, ....

lavh wrote: Tvz vc o caso de contratar um consultor C++