Java para desktop é perda de tempo?

Nem me fale disso - acho que em um sistema desktop escrito em MFC, 30% do código é para tentar fazer alguma coisa que o cliente quis mas não é trivialmente feito no MFC - citei a história de usar um label com fonte diferente dos outros labels, mas há coisas mais arrepiantes. Normalmente usa-se também alguma biblioteca de terceiros justamente para tentar acertar esses pontos cegos do MFC.

Um grande problema do MFC é que como ele é uma biblioteca bem antiga, muita gente se acostumou com ele e ainda usa as estruturas de dados bem básicas que vêm com ele - como a famigerada CString ou o CList, e nunca quis saber da STL (que não é nenhuma maravilha, na verdade, mas pelo menos é um pouco mais completa nesse ponto). Portanto, você pode encontrar programadores C++ com uma certa idade que não querem saber de aprender outra coisa - e continuam a criar sistemas usando a MFC em vez de alguma coisa mais portável ou menos esquisita.

[quote=entanglement][quote=ViniGodoy]
Citei a MFC pelos seguintes motivos:
a) É interessante conhecer a API do Windows, os padrões da Microsoft, e a bagunça que a MFC foi;
b) Se você está querendo se tornar um profissional do mercado desktop, provavelmente vai ter que manter sistemas feitos nisso.
[/quote]

Nem me fale disso - acho que em um sistema desktop escrito em MFC, 30% do código é para tentar fazer alguma coisa que o cliente quis mas não é trivialmente feito no MFC - citei a história de usar um label com fonte diferente dos outros labels, mas há coisas mais arrepiantes. Normalmente usa-se também alguma biblioteca de terceiros justamente para tentar acertar esses pontos cegos do MFC.

Um grande problema do MFC é que como ele é uma biblioteca bem antiga, muita gente se acostumou com ele e ainda usa as estruturas de dados bem básicas que vêm com ele - como a famigerada CString ou o CList, e nunca quis saber da STL (que não é nenhuma maravilha, na verdade, mas pelo menos é um pouco mais completa nesse ponto). Portanto, você pode encontrar programadores C++ com uma certa idade que não querem saber de aprender outra coisa - e continuam a criar sistemas usando a MFC em vez de alguma coisa mais portável ou menos esquisita. [/quote]

Quer saber onde mfc é amplamente usada ainda hoje? China. Impressionante como desenvolvem soluções com esse framework.

[quote=juliocbq][quote=entanglement][quote=ViniGodoy]
Citei a MFC pelos seguintes motivos:
a) É interessante conhecer a API do Windows, os padrões da Microsoft, e a bagunça que a MFC foi;
b) Se você está querendo se tornar um profissional do mercado desktop, provavelmente vai ter que manter sistemas feitos nisso.
[/quote]

Nem me fale disso - acho que em um sistema desktop escrito em MFC, 30% do código é para tentar fazer alguma coisa que o cliente quis mas não é trivialmente feito no MFC - citei a história de usar um label com fonte diferente dos outros labels, mas há coisas mais arrepiantes. Normalmente usa-se também alguma biblioteca de terceiros justamente para tentar acertar esses pontos cegos do MFC.

Um grande problema do MFC é que como ele é uma biblioteca bem antiga, muita gente se acostumou com ele e ainda usa as estruturas de dados bem básicas que vêm com ele - como a famigerada CString ou o CList, e nunca quis saber da STL (que não é nenhuma maravilha, na verdade, mas pelo menos é um pouco mais completa nesse ponto). Portanto, você pode encontrar programadores C++ com uma certa idade que não querem saber de aprender outra coisa - e continuam a criar sistemas usando a MFC em vez de alguma coisa mais portável ou menos esquisita. [/quote]

Quer saber onde mfc é amplamente usada ainda hoje? China. Impressionante como desenvolvem soluções com esse framework.[/quote]
É mesmo? Que tipo de projetos eles fazem com MFC?

Comentando o que postaram acima, já dei uma olhada em uns fontes de sistemas MFC e foi o suficiente pra nunca querer trabalhar com ela.
O Qt é algo realmente fantástico mesmo, estou estudando ele e é um framework que se consegue fazer muita coisa interessante com códigos relativamente simples. Reforço seu comentários sobre os signals and slots, realmente é um mecanismo muito bom do Qt.

[quote=matheuslmota][quote=juliocbq][quote=entanglement][quote=ViniGodoy]
Citei a MFC pelos seguintes motivos:
a) É interessante conhecer a API do Windows, os padrões da Microsoft, e a bagunça que a MFC foi;
b) Se você está querendo se tornar um profissional do mercado desktop, provavelmente vai ter que manter sistemas feitos nisso.
[/quote]

Nem me fale disso - acho que em um sistema desktop escrito em MFC, 30% do código é para tentar fazer alguma coisa que o cliente quis mas não é trivialmente feito no MFC - citei a história de usar um label com fonte diferente dos outros labels, mas há coisas mais arrepiantes. Normalmente usa-se também alguma biblioteca de terceiros justamente para tentar acertar esses pontos cegos do MFC.

Um grande problema do MFC é que como ele é uma biblioteca bem antiga, muita gente se acostumou com ele e ainda usa as estruturas de dados bem básicas que vêm com ele - como a famigerada CString ou o CList, e nunca quis saber da STL (que não é nenhuma maravilha, na verdade, mas pelo menos é um pouco mais completa nesse ponto). Portanto, você pode encontrar programadores C++ com uma certa idade que não querem saber de aprender outra coisa - e continuam a criar sistemas usando a MFC em vez de alguma coisa mais portável ou menos esquisita. [/quote]

Quer saber onde mfc é amplamente usada ainda hoje? China. Impressionante como desenvolvem soluções com esse framework.[/quote]
É mesmo? Que tipo de projetos eles fazem com MFC?

Comentando o que postaram acima, já dei uma olhada em uns fontes de sistemas MFC e foi o suficiente pra nunca querer trabalhar com ela.
O Qt é algo realmente fantástico mesmo, estou estudando ele e é um framework que se consegue fazer muita coisa interessante com códigos relativamente simples. Reforço seu comentários sobre os signals and slots, realmente é um mecanismo muito bom do Qt.[/quote]

Projetos de cftv. O programa embarcado normalmente é um activex para se acessar via browser. É super rápido, pois a mfc é muito enxuta. Ela gera executáveis eficientes no final das contas, apesar de ser um inferno trabalhar com ela.

Ai cara,
Se voce quer investir em aplicaões desktop, recomendo a usar C#(Windows Forms), tem um ide muito bom e como os outros tem dito é mais usado pelas organizações, eu já tive alguma experiencia nessa linguagem é bastante interessante até um certo ponto.
:arrow:

[quote=agune]Ai cara,
Se voce quer investir em aplicaões desktop, recomendo a usar C#(Windows Forms), tem um ide muito bom e como os outros tem dito é mais usado pelas organizações, eu já tive alguma experiencia nessa linguagem é bastante interessante até um certo ponto.
:arrow: [/quote]

Esse artigo é bem esclarecedor em se tratando de desempenho dos ambientes que necessitam de máquinas virtuais. Por aí dá para pesar a melhor solução para desktop, já que memória e processamento são requisitos para esse tipo de software.

Dê uma olhada em JavaFX. A Oracle está investindo bastante e agora tem instalador nativo.

Quando já estiver bem estável para linux será um avanço e tanto. Para windows já é uma boa alternativa.

Na versão 2.2 deverá estar bom para Linux. Vamos ver.

[quote=agune]Ai cara,
Se voce quer investir em aplicaões desktop, recomendo a usar C#(Windows Forms), tem um ide muito bom e como os outros tem dito é mais usado pelas organizações, eu já tive alguma experiencia nessa linguagem é bastante interessante até um certo ponto.
:arrow: [/quote]

Acho que como tudo em tecnologia, depende e precisa analisar!
C# com mono não é totalmente compativel com C# do .NET…
E se precisa rodar em linux???
E se precisa reaproveitar regras/componentes na Web e esse sim vai rodar em linux ??? Fazer Webservices??? Talvez…

Acho que quando vamos fazer algo de prateleira, acho que a primeira pergunta é … onde vai rodar… depois, o que vamos precisar fazer!!!
Dependendo do caso, o ideal pode ser C++, pode ser C, pode ser C# ou até mesmo PythonGTK…

Estou atualmente trabalhando em um sistema que compartilha rotinas entre módulos Web (rodando em Linux) e módulos Desktop (rodando em Windows mas que também funcionam perfeitamente em linux), usando Java e usando SWT e digo… o resultado final é totalmente satisfatório, inclusive se levar em conta a produtividade do desenvolvimento com Java + Eclipse!

fiz um trabalho de conclusão de curso em desktop swing java, são 7 jogos. ficaram interessantes. também tento montar uns sistemas desktop que ficam interessantes.

um cadastro de dentista, ou mesmo até um terminal para caixa de compras é possível fazer, e acredito que deva funcionar bem.
as vezes tenho a impressão que parece um pouco lento, mas esta lentidão tende a desaparecer com o uso do software, talvez o micro se acostume com o programa. claro cientificamente nada disso tem validade, mas acho que boas coisas podem ser feitas sim. inclusive prefiro java desktop do que web, quando parto para web uso o php.
se me mandar um email, para raghy@ig.com.br, envio o meu projeto de conclusão de curso que é em desktop, 7 jogos em java.

[quote=raghy]fiz um trabalho de conclusão de curso em desktop swing java, são 7 jogos. ficaram interessantes. também tento montar uns sistemas desktop que ficam interessantes.

um cadastro de dentista, ou mesmo até um terminal para caixa de compras é possível fazer, e acredito que deva funcionar bem.
as vezes tenho a impressão que parece um pouco lento, mas esta lentidão tende a desaparecer com o uso do software, talvez o micro se acostume com o programa. claro cientificamente nada disso tem validade, mas acho que boas coisas podem ser feitas sim. inclusive prefiro java desktop do que web, quando parto para web uso o php.
se me mandar um email, para raghy@ig.com.br, envio o meu projeto de conclusão de curso que é em desktop, 7 jogos em java.[/quote]

Para rodar uma aplicação java ou outra no desktop não há problema. O gargalo acontece na “quantidade” das aplicações java. Elas ocupam muita memória. Tem gente que vai falar aí que hardware não é problema, mas acaba sendo.

Imagina umas 5 aplicações java rodando no seu desktop? Só o eclipse no meu já come 2gb.

Em contrapartida o javafx está sendo preparado para isso. Vai poder ter um monte de aplicações rodando porque elas usam recursos nativos que já estão carregados no sistema. Quando rodar uma aplicação jfx não vai precisar subir todo o swing na memória ram.

[quote=juliocbq][quote=raghy]fiz um trabalho de conclusão de curso em desktop swing java, são 7 jogos. ficaram interessantes. também tento montar uns sistemas desktop que ficam interessantes.

um cadastro de dentista, ou mesmo até um terminal para caixa de compras é possível fazer, e acredito que deva funcionar bem.
as vezes tenho a impressão que parece um pouco lento, mas esta lentidão tende a desaparecer com o uso do software, talvez o micro se acostume com o programa. claro cientificamente nada disso tem validade, mas acho que boas coisas podem ser feitas sim. inclusive prefiro java desktop do que web, quando parto para web uso o php.
se me mandar um email, para raghy@ig.com.br, envio o meu projeto de conclusão de curso que é em desktop, 7 jogos em java.[/quote]

Para rodar uma aplicação java ou outra no desktop não há problema. O gargalo acontece na “quantidade” das aplicações java. Elas ocupam muita memória. Tem gente que vai falar aí que hardware não é problema, mas acaba sendo.

Imagina umas 5 aplicações java rodando no seu desktop? Só o eclipse no meu já come 2gb.
.[/quote]

Julio… isso também é meio relativo…
Tem aplicações em C# que também acabam consumindo muita memória…

Com Java e SWT é possível subir um sisteminha desktop consumindo algo em torno de 30 a 40MB de RAM… o restante vai ser aquilo que você efetivamente esta guardando na memória!

Acho que dependendo da aplicação… não tem jeito… o ideal é ir para um C++ por exemplo… ou até mesmo C… ai sim teremos ganhos realmente relevantes, porém estaremos perdendo muito em produtividade, pois no geral, os programadores dificilmente sabem trabalhar com C e C++, estes profissionais são mais caros… e são linguagens mais dificeis de trabalhar do que C# e Java (embora também exista uma boa produtividade com QT, wxWidgets, etc)!

Quando se fala de software de prateleira é uma coisa, quando se fala daquele sistema que o cara usa no dia-a-dia na empresa e na maior parte das vezes é a unica coisa que roda na maquina, junto com Office e navegador… a história muda! Precisamos levar em consideração outros fatores!

Com certeza, dificilmente eu usaria Java para algo de prateleira…

Isso é verdade é evidente a melhoria de performance. Até vi JavaFX rodando no iPad/Android!!!

[quote=jmmenezes][quote=juliocbq][quote=raghy]fiz um trabalho de conclusão de curso em desktop swing java, são 7 jogos. ficaram interessantes. também tento montar uns sistemas desktop que ficam interessantes.

um cadastro de dentista, ou mesmo até um terminal para caixa de compras é possível fazer, e acredito que deva funcionar bem.
as vezes tenho a impressão que parece um pouco lento, mas esta lentidão tende a desaparecer com o uso do software, talvez o micro se acostume com o programa. claro cientificamente nada disso tem validade, mas acho que boas coisas podem ser feitas sim. inclusive prefiro java desktop do que web, quando parto para web uso o php.
se me mandar um email, para raghy@ig.com.br, envio o meu projeto de conclusão de curso que é em desktop, 7 jogos em java.[/quote]

Para rodar uma aplicação java ou outra no desktop não há problema. O gargalo acontece na “quantidade” das aplicações java. Elas ocupam muita memória. Tem gente que vai falar aí que hardware não é problema, mas acaba sendo.

Imagina umas 5 aplicações java rodando no seu desktop? Só o eclipse no meu já come 2gb.
.[/quote]

Julio… isso também é meio relativo…
Tem aplicações em C# que também acabam consumindo muita memória…

Com Java e SWT é possível subir um sisteminha desktop consumindo algo em torno de 30 a 40MB de RAM… o restante vai ser aquilo que você efetivamente esta guardando na memória!

Acho que dependendo da aplicação… não tem jeito… o ideal é ir para um C++ por exemplo… ou até mesmo C… ai sim teremos ganhos realmente relevantes, porém estaremos perdendo muito em produtividade, pois no geral, os programadores dificilmente sabem trabalhar com C e C++, estes profissionais são mais caros… e são linguagens mais dificeis de trabalhar do que C# e Java (embora também exista uma boa produtividade com QT, wxWidgets, etc)!

Quando se fala de software de prateleira é uma coisa, quando se fala daquele sistema que o cara usa no dia-a-dia na empresa e na maior parte das vezes é a unica coisa que roda na maquina, junto com Office e navegador… a história muda! Precisamos levar em consideração outros fatores!

Com certeza, dificilmente eu usaria Java para algo de prateleira…

[/quote]

Foi isso que eu quis dizer. Aplicações “corriqueiras”. Coisa que você usa toda hora e em quantidade. Sistema coorporativo é ferramenta que vai rodar com ou sem nenhuma outra aplicação dando suporte então você não precisa se preocupar com esse runtime largo(nem tanto).

[quote=sergiotaborda][quote=yschmitzz]Minha dúvida é basicamente essa. estudar essa linguagem para desenvolver apenas aplicações para desktop é perda de tempo?
na verdade, quero mais a opniao de voces. uma linguagem multiplataforma, funciona em dispositivos moveis, com uma grande robustes no desenvolvimento para web, até porque o mercado de trabalho voltado para java, a grande parte é para desenvolvimento para web.
claro que nenhum conhecimento adguirido é um desperdicio de tempo, mas tendo em vista que minha vontade é desenvolves sistemas para desktop seria interesante investir em outras linguagens que sejam menos voltada para web?[/quote]

Primeiro tem que definir o que significa “aplicação para desktop” : jogos ? editores ? front-ends para aplicações coorporativas ? pontos de venda (pdv) ? etc…

Para desktop , em java , o assunto é javaFX. Swing não é mais relevante. Vc teria que criar algo parecido ao Fx para aproveitar o swing (binding sobretudo).
Mas para jogos, por exemplo, isso é menos relevante e swing se resume a java2D em FX dá para fazer melhor com 3D e efeitos de iluminação.

Existem muitas aplicações java desktop emboras as mais famosas sejam o eclipse e o netbeans, existem editores de SQL por exemplo e players de musica. É que quando se usa swing o cara tem tendencia a fazer um UI que é feio , mas isso não é culpa do swing é culpa do artista. Java é tão capaz de criar UI atraentes como qualquer outra linguagem, mas com minimo esforço.

Para distribuição também é simples. Desde o tradicional instalador até jws tudo é válido, e até applets que se convertem em aplicações dektop.

Jogos é um campos mais lato e tlv ajam opções melhores dependendo do que vc quer fazer.

Se vc quer algo que funcione também em android ou iphone não ha nada por enquanto e a sua opção é programar nativamente nesses caras ou em html 5 usando canvas. Mas a Oracle está prometendo que o javaFX chegará a essas plataformas também … a ver vamos…

Para aplicações coorporativas o html é rei e frameworks como wicket, zk ou vaaddin podem ser mais produtivos e fornecer resultados visualmente atraentes. Mas tudo depende da aplicação.

Aprender java desktop não é perda de tempo até porque os frameworks web estão migrando para arquiteturas mais parecidas com desktop, e tudo o que vc pode fazer em web pode fazer em desktop. Imagine assim : fazer desktop é como criar seu proprio browser. mas continuará podendo usar web por baixo dos panos como REST por exemplo.

É tudo uma questão de arquitetura, design e constrangimentos. A principio tudo é possivel.
A questão é se compensa financeiramente.

Se vc fizer o proximo angry birsds em java, todos vão usar e não vai ser por ser em java que não vai ficar conhecido. Mas o produto tem que ser bom.
E fazer um bom produto tem a mesma dificuldade em qualquer linguagem. [/quote]

Concordo plenamente e reforço o argumento. Oras, por que não usar Java e JavaFx, por exemplo? Por que o preconceito contra o Java no desktop? Para a interface JavaFX está show de bola e representa uma evolução enorme em relação ao Swing. Além disso, estudando a plataforma Java vc abre caminho para desenvolver tanto em desktop, quanto mobile e web com qualidade e robustez.
Esse argumento que o desktop está morto pra mim é bobagem. A maioria dos sistemas comerciais vendidos prontos são para desktop. Verifique o software da sua loja preferida no comércio e veja se é em desktop ou web. Verifique o software dos caixas de supermercado, por exemplo, e veja. Com certeza a esmagadora maioria será um software desktop.

Gosto muito de java pra desktop, mas o meu preconceito com ele é a descompilação da aplicação final . O que tornar inviável o desenvolvimento desktop na minha concepção.

Gosto muito de java pra desktop, mas o meu preconceito com ele é a descompilação da aplicação final . O que tornar inviável o desenvolvimento desktop na minha concepção.[/quote]

esse é só um dos problemas… outros dois que também teriam são, primeiro que a api padrão de desktop, o swing é meio ruimzinho, os gerenciadores de layout são bem ruimzinhos de se trabalhar, em contrapartida também o mercado não usa muito, o investimento também não é tão alto quanto em outras partes como jee por exemplo…

Gosto muito de java pra desktop, mas o meu preconceito com ele é a descompilação da aplicação final . O que tornar inviável o desenvolvimento desktop na minha concepção.[/quote]

esse é só um dos problemas… outros dois que também teriam são, primeiro que a api padrão de desktop, o swing é meio ruimzinho, os gerenciadores de layout são bem ruimzinhos de se trabalhar, em contrapartida também o mercado não usa muito, o investimento também não é tão alto quanto em outras partes como jee por exemplo…[/quote]

Não vejo isso como problema… basta compilar o Java para nativo… se realmente tiver essa necessidade.

Já usei este cara aqui, mas é pago:
http://www.excelsior-usa.com/jet.html

A diferença no carregamento da aplicação é a principal, entretanto não vi diferença de performance rodando os .jar e os executaveis em maquinas com mais de 1 nucleo…

Tem alguns casos que nem a diferença compensa… as vezes cai de 3 segundos para 1 segundo… 3 segundos para carregar a aplicação dependendo do tipo é irrelevante…

Tem alguns apps comerciais que usam esse cara…

Não acho que afirmar que Java é ruim para desktop baseia em pré-conceito. Sem falar no Swing ser ou não fácil/produtivo, eu poderia citar os seguintes motivos:

Em primeiro lugar, é difícil fazer o deploy de uma aplicação Java desktop. Você tem que garantir que o sistema alvo tenha uma VM configurada corretamente. Na hora de rodar uma aplicação Java, você normalmente tem que passar parâmetros para a VM (tal como o -XMX ou -XMS) e isso não pode ser feito de forma conveniente, dentro do .jar, por exemplo. Finalmente, é complicado criar atalhos para o .jar (normalmente você vai ter que criar um arquivo de lote, e associar o atalho a ele, para ele disparar o .jar).

Você pode resolver isso com um instalador, duplicando a VM na máquina do usuário e, usando a estratégia do Eclipse, criando um executável para disparar sua aplicação Java (no lugar do arquivo de lote).

Uma das coisas mais básicas em Desktop é também pegar o caminho onde a aplicação está localizada. Isso é trivial em várias linguagens, como C++ ou C#, mas é virtualmente impossível em Java. Especialmente se levar em conta detalhes como as restrições do Security Manager.

O java não tem qualquer integração com o UAC ou qualquer outro recurso mais específico
do SO (Active Directory, OpenGL, DirectX, Direct2D, AviCap, etc). Só nas últimas versões foi possível marcar um arquivo criado como “executável” no Linux, por exemplo. Em C#, você pode solicitar o UAC por um arquivo manifesto. Em C++, isso é feito usando uma opção na compilação. Você até pode apelar para JNI e JNA, mas isso não é fácil e nem conveniente (bem diferente dos unsafe methods do C#).