Migrar aplicação de Qt para Java: Valeria à pena?

Você precisa fazer as contas do esforço (porque muita coisa você vai ter de reimplementar e retestar, e talvez até mudar a forma de fazer), e usar um framework decente para desenhar as telas. Não use o NetBeans puro, por exemplo - use algo como o Genesis.
É que o mesmo problema que você vê na sua aplicação com Qt vai aparecer no programa em Swing ou SWT se você não impuser um framework decente.

Não entendi o problema… você concorda, seu chefe também. Achar mão de obra vai ficar cada vez mais difícil… migra logo. (;

Mas fica esperto, só começa a adicionar funcionalidades quando o aplicativo em java estiver bacana, funcionando direintho… enquanto isso, vai ter que fazer malabrismo para manter as versões compatíveis.

thingol:

Você precisa fazer as contas do esforço (porque muita coisa você vai ter de reimplementar e retestar, e talvez até mudar a forma de fazer), e usar um framework decente para desenhar as telas. Não use o NetBeans puro, por exemplo - use algo como o Genesis.
É que o mesmo problema que você vê na sua aplicação com Qt vai aparecer no programa em Swing ou SWT se você não impuser um framework decente.

Concordo com você thingol, porque já fiz algumas aplicações Swing e sei como é penoso trabalhar com o mesmo sem o auxilio de nenhum framework…

bandrade:

Não entendi o problema… você concorda, seu chefe também. Achar mão de obra vai ficar cada vez mais difícil… migra logo. (;

Mas fica esperto, só começa a adicionar funcionalidades quando o aplicativo em java estiver bacana, funcionando direintho… enquanto isso, vai ter que fazer malabrismo para manter as versões compatíveis.

Não fui eu quem escreveu a aplicação em Qt, mas sei que o desenvolvimento todo levou dois anos para ser concluído… por isso que tenho que pesar bem essa migração…

Se for considerar apenas o argumento do seu chefe, eu ficaria com o pé atrás. Tudo bem que Qt é uma biblioteca pouco popular por aqui (assim como muitas outras escritas em C ou C++, por exemplo: wxWidgets ou GTK), mas muito programador Java é mais especializado em Struts do que Swing, e das pessoas que conheço que escrevem em Swing, não sabem fazer um código decente - utilizando os layouts corretos e sem usar copiar e colar.

O problema da escrita procedural depende tão somente das pessoas responsáveis pelo desenho do projeto. Se elas não tem um conhecimento da orientação a objetos, vão fazer um código procedural na linguagem Java também. Então fica esperto nesse detalhe.

Mas não que eu esteja dizendo pra deixar como está. A minha opinião pessoal deve contar muito pouco nesse caso, mas por mim a aplicação seria na web, porque é mais fácil desenhar uma tela em HTML do que em Swing, e existem mais profissionais pra essa área.

E aí, já pensou nessa possibilidade?

Pelo que você falou, o sistema nunca terminou de ser construido… você vai modelando e criando em Java e assim que surgir uma demanda para o antigo vc atende, mas ao mesmo tempo já adiciona essa funcionalidade ao sistema Java. Vai chegar um momento que você para de atender a novas solicitações adicionado apenas no sistema Java, daí é só colocar o sistema Java para rodar.

Porque fazer um aplicativo desktop e não web? Já pensaram nessas mudanças tb?

Só tem que ficar esperto para não virar outro projeto interminável, ainda mais esses projetos de evolução/versão 2.0. É a maior enrolação…

Por isso que eu precisaria escolher um framework decente para Swing… Também concordo que tem mais gente que manja de java para web do que para desktop (digo conhecer DE VERDADE).

Não haveria esse problema, atualmente sou o único desenvolvedor e, apesar de não ser nenhum Martin Fowler, acho que conheço bem OO.

Leonardo3001:

Mas não que eu esteja dizendo pra deixar como está. A minha opinião pessoal deve contar muito pouco nesse caso, mas por mim a aplicação seria na web, porque é mais fácil desenhar uma tela em HTML do que em Swing, e existem mais profissionais pra essa área.
E aí, já pensou nessa possibilidade?

Então… eu terminei há pouco tempo uma outra aplicação aqui na empresa, que conversa com a mesma base de dados desta aplicação em Qt, mas fiz para Web, usando Java… É um ponto a se pensar, mas preciso ver a experiência dos usuários também, que já estão acostumados há anos a usar essa aplicação em Desktop. Outro ponto é que não sei se eu conseguiria atingir em uma aplicação web o mesmo nível de desempenho que uma aplicação desktop escrita em C++, e os usuários perceberiam isso… A aplicação que fiz para web usa muito ajax então ficou bem rápida, mas ainda tenho muitas dúvidas…

Pelo que você falou, o sistema nunca terminou de ser construido… você vai modelando e criando em Java e assim que surgir uma demanda para o antigo vc atende, mas ao mesmo tempo já adiciona essa funcionalidade ao sistema Java. Vai chegar um momento que você para de atender a novas solicitações adicionado apenas no sistema Java, daí é só colocar o sistema Java para rodar.

Porque fazer um aplicativo desktop e não web? Já pensaram nessas mudanças tb?

Só tem que ficar esperto para não virar outro projeto interminável, ainda mais esses projetos de evolução/versão 2.0. É a maior enrolação…

E um sistema pára de ser construído?
Acho que não existe aplicação perfeita, que não precise ou passa ser melhorada…

Esse ponto que você falou sobre ir criando as funcionalidades na aplicação Java é possível, o único detalhe é que demoraria um pouco, pois o projeto em Qt é grande…

Obrigado pelas opiniões!

Reescrever o sistema TODO é loucura. É jogar muito dinheiro no ralo. Já pensaram em utilizar uma solução híbrida? Mantenham a aplicação como está, e embutam o runtime de uma linguagem moderna, desenvolvam as novas features usando esta linguagem e, por fim, vão migrando as funcionalidades antigas conforme for surgindo oportunidade.

Migrar tudo é uma enorme burrada, vai custar uma fortuna, vai criar uma enormidade de bugs novos, vai descontentar todos stack holders pois verão pouco retorno nesse investimento. Utilize Java ou .NET embarcado, vai ser muito mais prático. Você pode utilizar, por exemplo, o qtsharp para facilmente fazer a aplicação em código gerenciado conversar com o QT, com Java vai ser via a tortura do JNI. De uma olhada em como embutir o mono, uma implementação open source do .net, você vai ficar surpreso em como é simples e leve - diferente do JRE da Sun.

louds:

Reescrever o sistema TODO é loucura. É jogar muito dinheiro no ralo. Já pensaram em utilizar uma solução híbrida? Mantenham a aplicação como está, e embutam o runtime de uma linguagem moderna, desenvolvam as novas features usando esta linguagem e, por fim, vão migrando as funcionalidades antigas conforme for surgindo oportunidade.

Migrar tudo é uma enorme burrada, vai custar uma fortuna, vai criar uma enormidade de bugs novos, vai descontentar todos stack holders pois verão pouco retorno nesse investimento. Utilize Java ou .NET embarcado, vai ser muito mais prático. Você pode utilizar, por exemplo, o qtsharp para facilmente fazer a aplicação em código gerenciado conversar com o QT, com Java vai ser via a tortura do JNI. De uma olhada em como embutir o mono, uma implementação open source do .net, você vai ficar surpreso em como é simples e leve - diferente do JRE da Sun.

Atualmente temos Java swing, java para web + Javascript e C++ rodando nas aplicações… acho que introduzir mais uma (C#) iria aumentar demais a complexidade das coisas. Na hora de arrumar um profissional, o problema do meu chefe pioraria, pois ele teria que achar profissional com mais skills e não menos, já que terminar de migrar tudo para C# demoraria muito, até lá ainda teria muita coisa em Qt.

Talvez algo como o Qt Jambi fosse um meio-termo interessante para a migração, mas sei pouco ainda sobre este projeto…

Olá, amigo…

Eu mesmo que java esteja mais fácil de implementar, para uma aplicação desktop java pode vir a calhar mas avança rápido. Minha opnião pessoal é que para um desktop prefiro manter a versão nativa, se precisar portar para outros SO, eu primeiro iria por wxWidgets com C++ se os recursos que tem forem razoáveis ainda que necessite desenpenho e se manter nos sistemas GNU/Linux recomendo o wxPython(apesar de ser portável, como dizem, para outros SO) acredito que terá que manter com o interpretador python. Java, sei que está superando a expectativas enquanto muitas coisas são nativas ainda pode ser uma nova aventura para os desencolvedores e para os usuários podem acarretar "aos olhos " deles uma perda de performance no repaint das telas e processamentos gerais.

Recomendo, se possível, a reescrita para OO seu projeto em C++ , em IMHO beira quase ao ideal de uma aplicação desktop.

Concordo com o Louds. Não tem que migrar tudo de uma vez, até porque manter dois sistemas atualizados é algo insano e a possibilidade do novo projeto ir pro buraco porque você ainda tem de dar manutenção no antigo é enorme.

Eu prefiro o método “cancerígeno”: vai migrando as funcionalidades aos poucos, desativando no antigo e utilizando no novo até que o mesmo engula todo o antigo projeto.

Pelo menos vc tem a “vantagem” (isso depende do ponto de vista) de parte da
regra de negócios estar no banco de dados. Facilita qualquer conversão.

Ao contrário de que disseram por aqui, não acho que uma aplicação Web tenha
mais recursos que uma desktop e sim o contrário. Ainda acho browser muito lento
mesmo com Ajax e se for uma aplicação para rede fechada não tem porque a
obrigatoriedade. Mas é uma possibilidade.

Se for migrar, sugiro que vá fazendo o que for surgindo de novo no Java (se for
a linguagem escolhida) e ir fazendo pouco a pouco as funcionalidades já
existentes. Sem traumas.

Este tipo de processo deve custar uma nota. O cliente está disposto a pagar?

marciosantri:

Pelo menos vc tem a “vantagem” (isso depende do ponto de vista) de parte da
regra de negócios estar no banco de dados. Facilita qualquer conversão.

Ao contrário de que disseram por aqui, não acho que uma aplicação Web tenha
mais recursos que uma desktop e sim o contrário. Ainda acho browser muito lento
mesmo com Ajax e se for uma aplicação para rede fechada não tem porque a
obrigatoriedade. Mas é uma possibilidade.

Se for migrar, sugiro que vá fazendo o que for surgindo de novo no Java (se for
a linguagem escolhida) e ir fazendo pouco a pouco as funcionalidades já
existentes. Sem traumas.

Este tipo de processo deve custar uma nota. O cliente está disposto a pagar?

O desenvolvimento é para consumo interno, “produto caseiro”. Digamos que o preço está incluso em meu salário

Minha dúvida é em como fazer a integração entre o que está pronto em Java com o que já existe com o Qt. Para uma nova tela em Java, por exemplo, abriria a mesma através da criação de um novo processo no Qt? Ficaria lento eu acho… e cada tela minha precisaria ter um main()…
Pelo menos até migrar tudo…

Idéias?

Obrigado a todos pelas respostas!

cassio:

marciosantri:

Pelo menos vc tem a “vantagem” (isso depende do ponto de vista) de parte da
regra de negócios estar no banco de dados. Facilita qualquer conversão.

Ao contrário de que disseram por aqui, não acho que uma aplicação Web tenha
mais recursos que uma desktop e sim o contrário. Ainda acho browser muito lento
mesmo com Ajax e se for uma aplicação para rede fechada não tem porque a
obrigatoriedade. Mas é uma possibilidade.

Se for migrar, sugiro que vá fazendo o que for surgindo de novo no Java (se for
a linguagem escolhida) e ir fazendo pouco a pouco as funcionalidades já
existentes. Sem traumas.

Este tipo de processo deve custar uma nota. O cliente está disposto a pagar?

O desenvolvimento é para consumo interno, “produto caseiro”. Digamos que o preço está incluso em meu salário

Minha dúvida é em como fazer a integração entre o que está pronto em Java com o que já existe com o Qt. Para uma nova tela em Java, por exemplo, abriria a mesma através da criação de um novo processo no Qt? Ficaria lento eu acho… e cada tela minha precisaria ter um main()…
Pelo menos até migrar tudo…

Idéias?

Obrigado a todos pelas respostas!

Eu não faria integração entre programas. Pegaria uma funcionalidade do programa e a faria
totalmente no Java, sem dependências do Qt.
A maneira de fazer os sistemas conversarem é o banco de dados.
Por exemplo: um cadastro de clientes que chama umas 2 ou 3 telas. Não fique chamando
as telas do Qt, faça-as completamente no Java. Facilita seus testes e essa rotina não
precisará ser “ajustada” posteriormente.

louds:

Reescrever o sistema TODO é loucura. É jogar muito dinheiro no ralo. Já pensaram em utilizar uma solução híbrida? Mantenham a aplicação como está, e embutam o runtime de uma linguagem moderna, desenvolvam as novas features usando esta linguagem e, por fim, vão migrando as funcionalidades antigas conforme for surgindo oportunidade.

Migrar tudo é uma enorme burrada, vai custar uma fortuna, vai criar uma enormidade de bugs novos, vai descontentar todos stack holders pois verão pouco retorno nesse investimento. Utilize Java ou .NET embarcado, vai ser muito mais prático. Você pode utilizar, por exemplo, o qtsharp para facilmente fazer a aplicação em código gerenciado conversar com o QT, com Java vai ser via a tortura do JNI. De uma olhada em como embutir o mono, uma implementação open source do .net, você vai ficar surpreso em como é simples e leve - diferente do JRE da Sun.

leve…nem tanto… no linux prefiro java ao mono…ao mono de certa forma está preso as patentes da ms…não é tão open source assim…

marciosantri:

cassio:

marciosantri:

Pelo menos vc tem a “vantagem” (isso depende do ponto de vista) de parte da
regra de negócios estar no banco de dados. Facilita qualquer conversão.

Ao contrário de que disseram por aqui, não acho que uma aplicação Web tenha
mais recursos que uma desktop e sim o contrário. Ainda acho browser muito lento
mesmo com Ajax e se for uma aplicação para rede fechada não tem porque a
obrigatoriedade. Mas é uma possibilidade.

Se for migrar, sugiro que vá fazendo o que for surgindo de novo no Java (se for
a linguagem escolhida) e ir fazendo pouco a pouco as funcionalidades já
existentes. Sem traumas.

Este tipo de processo deve custar uma nota. O cliente está disposto a pagar?

O desenvolvimento é para consumo interno, “produto caseiro”. Digamos que o preço está incluso em meu salário

Minha dúvida é em como fazer a integração entre o que está pronto em Java com o que já existe com o Qt. Para uma nova tela em Java, por exemplo, abriria a mesma através da criação de um novo processo no Qt? Ficaria lento eu acho… e cada tela minha precisaria ter um main()…
Pelo menos até migrar tudo…

Idéias?

Obrigado a todos pelas respostas!

Eu não faria integração entre programas. Pegaria uma funcionalidade do programa e a faria
totalmente no Java, sem dependências do Qt.
A maneira de fazer os sistemas conversarem é o banco de dados.
Por exemplo: um cadastro de clientes que chama umas 2 ou 3 telas. Não fique chamando
as telas do Qt, faça-as completamente no Java. Facilita seus testes e essa rotina não
precisará ser “ajustada” posteriormente.

Olá Marcio,

Entendo seu ponto de vista e concordo com ele. O problema é que em várias telas eu tenho um esquema de hierarquia, onde novas são abertas mas dependem das telas anteriores. Atualmente muitas coisas que são resultados de processamento em telas “filhas” refletem o estado das telas “pais” e eu não gostaria de ter que ir ao banco de dados e pesquisar para poder atualizar esse estado. Existe uma comunicação entre as janelas que se eu for fazer separando as janelas Java das em Qt, terei que usar QProcess e ficar manipulando os streams entre processos, o que é um pouco trbaalhoso e será jogado fora conforme eu for migrando também as janelas “pais”.
Mas é uma solução

Agora entendo melhor seu problema. Realmente telas muito dependentes são complicadas
de manter ainda mais de migrar. Eu nunca mexi com QProcess. Ao que me consta não é uma
biblioteca da MicroSoft? A troca de informações do QProcess entre os programas garante
que o que sair de um lado vai chegar EXATAMENTE do outro? Digo isso porque já tive problemas
com ferramentas do tipo, lembrando que não sei quase nada (ou nada) de QProcess.

marciosantri:

Agora entendo melhor seu problema. Realmente telas muito dependentes são complicadas
de manter ainda mais de migrar. Eu nunca mexi com QProcess. Ao que me consta não é uma
biblioteca da MicroSoft? A troca de informações do QProcess entre os programas garante
que o que sair de um lado vai chegar EXATAMENTE do outro? Digo isso porque já tive problemas
com ferramentas do tipo, lembrando que não sei quase nada (ou nada) de QProcess.

Não Marcio, o QProcess é uma classe do próprio Qt. Pode imaginar ela como se fosse o Runtime.exec() do Java.
Para implemetar isso certinho quando há gtroca de informação entre os processos, tem que sincronizar a coisa toda, tipo um fica escutando e assim que o outro envia algo, ele recebe e processa, em seguida o processo pode tomar o sentido inverso, etc. Enfim, meio chatinho …