Java para desktop é perda de tempo?

Gosto muito de Java. Muito mesmo.
Acho válido aprender a trabalhar um pouco com Swing, mas comercialmente acho que não vale a pena.

Java é para Web. Ponto.
Para desktop acredito que existam soluções muito melhores como o Qt (C++) e o C#.

[]'s

davidbuzatto:

Gosto muito de Java. Muito mesmo.
Acho válido aprender a trabalhar um pouco com Swing, mas comercialmente acho que não vale a pena.

Java é para Web. Ponto.
Para desktop acredito que existam soluções muito melhores como o Qt (C++) e o C#.

[]'s

Acredito que o número de aplicações para Web hoje sejam muito maiores. Mas ainda há empresas contratando programadores para Java Desktop. Em sites de Emprego relacionados a Java, sempre tem alguma coisa.

O mercado é muito variado, conheço empresas que tem projetos voltados mais para lado “desktop” da coisa mas que acabam dando mais ênfase em projetos web. Mas certamente aprender java desktop, já faz com que o programador fique com uma carga de conhecimentos java muito boa para engressar na parte web.

Depende… se você está falando do mercado desktop, o de aplicações que vão para o usuário final, tais como players de vídeo, browsers e game, sim é pura perda de tempo. Seria mais interessante investir seu tempo em plataformas que as empresas de desktop usam, no caso:

• C++ e QT;
• C++ e MFC;
• C#

ViniGodoy:

Depende… se você está falando do mercado desktop, o de aplicações que vão para o usuário final, tais como players de vídeo, browsers e game, sim é pura perda de tempo. Seria mais interessante investir seu tempo em plataformas que as empresas de desktop usam, no caso:

• C++ e QT;
• C++ e MFC;
• C#

MFC ainda é usada em projetos novos? Ouvi dizer que é um parto trabalhar com ela.

A tendencia é ela sumir mesmo.

Especialmente depois do WinForms e do Win8.

Vlw pessoal. realmente sempre tive interesse na linguagem c++, mas na minha opinião, o maior problema da linguagem é a falta de conteúdo dela na web.
conheço um pouco de c# e acho bem interessante, fiz um teste pesquisando no google sobre baixar arquivos com c++, não encontrei, mas fazendo a mesma pesquisa para c# encontrei muito material, isso desânimo no aprendizado de qualquer coisa

Vlw pessoal. realmente sempre tive interesse na linguagem c++, mas na minha opinião, o maior problema da linguagem é a falta de conteúdo dela na web.
conheço um pouco de c# e acho bem interessante, fiz um teste pesquisando no google sobre baixar arquivos com c++, não encontrei, mas fazendo a mesma pesquisa para c# encontrei muito material, isso desânimo no aprendizado de qualquer coisa

Desculpinha esfarrapada, hein?

Dica de materiais: http://pontov.com.br/site/cpp/46-conceitos-basicos/88-roadmap-c
Veja nos links, há um livro inteiro para iniciantes completamente gratuito.

Sobre o compilador, visual C++:
http://pontov.com.br/site/cpp/41-visual-c
http://msdn.microsoft.com/pt-br/library/60k1461a.aspx

Para um bom guia de referência:
http://www.cplusplus.com/reference/

Para material sobre QT:
http://qt.nokia.com/learning

Sobre a linguagem C:
http://pontov.com.br/site/cpp/61-aprendendo-o-c

E isso é só uma pequeníssima fração do conteúdo que existe na web.
Provavelmente, o C e o C++ estão entre as linguagens com maior conteúdo na internet.

O forte do Java é justamente a plataforma.
Invista no conhecimento da plataforma !

Vlw pessoal, agradeço mais uma vez pela ajuda.
vou estudar C++ a fundo, apesar de ainda achar sua sintax estranha, mas isso nao é problema, só uma questão de costume
vou estudar o básico pela internet depois comprar algum livro para iniciante
o que acho interessante também é o fato de poder escolher desenvolver com o C++ puro ou com o .Net, tornando depois o aprendizado de C# mais fácil que depois tornará o aprendizado em Java também mais fácil
Mas se possível me tira uma dúvida, o Java vem se atualizado com o tempo, Java 1.4, 1.5, 1.6 etc, o .Net também, o C++ também vem se atualizado com o tempo?
ótimos link vinygodoy, dei uma olhada por alto, ótimo ponto de partida

Tanto o C++ quanto o C# estão se atualizando frequentemente.

Se há algo que é constante em informática é que as coisas ou se atualizam (e muito frequentemente) ou morrem.

Que eu saiba, nem o Java, nem o C# ou o C++ estão mortos.

Recentemente houve uma atualização grande na sintaxe do C++ (C++11, antigamente chamado de C++0X) que nem foi ainda completamente implementada, para ter uma idéia. O C++ não é mais aquele da edição 1 do livro do Stroustrup

entanglement:

Tanto o C++ quanto o C# estão se atualizando frequentemente.

Se há algo que é constante em informática é que as coisas ou se atualizam (e muito frequentemente) ou morrem.

Que eu saiba, nem o Java, nem o C# ou o C++ estão mortos.

Recentemente houve uma atualização grande na sintaxe do C++ (C++11, antigamente chamado de C++0X) que nem foi ainda completamente implementada, para ter uma idéia. O C++ não é mais aquele da edição 1 do livro do Stroustrup :)

E nem o do deitel. Gosto dessa linguagem porque sempre existem novas especificações. É realmente muito flexível.

matheuslmota:

ViniGodoy:

Depende… se você está falando do mercado desktop, o de aplicações que vão para o usuário final, tais como players de vídeo, browsers e game, sim é pura perda de tempo. Seria mais interessante investir seu tempo em plataformas que as empresas de desktop usam, no caso:

• C++ e QT;
• C++ e MFC;
• C#

MFC ainda é usada em projetos novos? Ouvi dizer que é um parto trabalhar com ela.

Ou as pessoas usam Qt (devido também ao fato de ser multiplataforma - portanto fica super-fácil escrever um programa desktop relativamente leve que funcione no Windows e no MacOSX e no Linux com uma base comum de código) ou então WinForms e Metro (Windows 8 ). Não é porque a Nokia (que era a dona do Qt) está indo para o buraco que você vai ficar sem pai nem mãe, já que a Nokia vendeu o negócio para a Digia, que parece bem melhor das pernas porque não depende de algum mal-humor do sr. Stephen Elop.

Eu já trabalhei com MFC tempo suficiente para saber que ela é muito complicada de se usar - uma coisa boboca como mudar a fonte de apenas um label em um form já é complicada demais para o meu gosto, a menos que você comece a usar forms HTML em programas MFC, deixando-os muito pesados. Além disso, como MFC depende muito de wizards, se você tiver cometido um erro bobo em um diálogo qualquer, o mais rápido é salvar o código dos eventos em algum lugar, matar a classe que representa o diálogo, e rodar o wizard tudo de novo. Argh argh argh.
EDIT - eu tinha me esquecido que não é necessário redesenhar a tela, apenas reassociar o resource com a classe refeita com o Wizard e reassociar os eventos - mesmo assim é um porre.

entanglement:

matheuslmota:

ViniGodoy:

Depende… se você está falando do mercado desktop, o de aplicações que vão para o usuário final, tais como players de vídeo, browsers e game, sim é pura perda de tempo. Seria mais interessante investir seu tempo em plataformas que as empresas de desktop usam, no caso:

• C++ e QT;
• C++ e MFC;
• C#

MFC ainda é usada em projetos novos? Ouvi dizer que é um parto trabalhar com ela.

Ou as pessoas usam Qt (devido também ao fato de ser multiplataforma - portanto fica super-fácil escrever um programa desktop relativamente leve que funcione no Windows e no MacOSX e no Linux com uma base comum de código) ou então WinForms e Metro (Windows 8 ). Não é porque a Nokia (que era a dona do Qt) está indo para o buraco que você vai ficar sem pai nem mãe, já que a Nokia vendeu o negócio para a Digia, que parece bem melhor das pernas porque não depende de algum mal-humor do sr. Stephen Elop.

Eu já trabalhei com MFC tempo suficiente para saber que ela é muito complicada de se usar - uma coisa boboca como mudar a fonte de apenas um label em um form já é complicada demais para o meu gosto, a menos que você comece a usar forms HTML em programas MFC, deixando-os muito pesados. Além disso, como MFC depende muito de wizards, se você tiver cometido um erro bobo em um diálogo qualquer, o mais rápido é salvar o código dos eventos em algum lugar, matar a classe que representa o diálogo, e rodar o wizard (e desenhar a tela - argh) tudo de novo. Argh argh argh.

Eu já trabalhei com a MFC e você tem total razão. Esse Framework é uma bagunça total. Em contrapartida o qt segue totalmente Orientado a Objetos e utiliza MVC. O mecanismo mas prático que já vi para implementar o padrão Observer é o sistema de sinais e slots dele.

Só esclarecendo (pq meu post foi meio desleixado mesmo).

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.

Obviamente, não é para sair criando novos sistemas nisso. Com QT, hoje em dia, nem sequer isso faz sentido.

Até porque, pelo que me informei, após o Metro, o Windows não só trata uma nova interface gráfica, mas também uma nova API, mais simples de usar. Portanto, passa a ter cada vez menos sentido estudar MFC e os livros WinAPI do Petzold.

Amém, se depender de mim, nunca mais declaro um lpszNome.

Eu não tenho experiência desktop fora Swing mas Qt pelo que leio na internet também não é a bala de prata pra todas as situações não

Em muitos casos ele é igual ao Swing, adicionando overhead por não usar controles nativos e também não simulando perfeitamente a aparência nativa, fora o tamanho do .exe

Dúvida que isso afete? Tenta escrever um concorrente do uTorrent (superleve) com ele e faça as pessoas usarem. Tenta concorrer com apps nativas no Mac onde o pessoal é bitolado pela aparência nativa

O VLC, player de vídeo q eu uso é feito em Qt e eu odeio o tempo de carregamento dele, mas não sei se a culpa é do Qt

É obvio, não existe bala de prata.

O QT tem uma premissa forte, a de ser portável em muitas plataformas e isso obviamente vai contra o ideal do MicroTorrent.
Existem outras alternativas com outras premissas, e o que não falta no mundo C++ são escolhas.

Eu mesmo já fiz games usando APIs leves, como a SDL. Ou mesmo WinAPI + DirectX direto.

Você pode usar wxWidgets, GTK ou mesmo, fazer um app usando diretamente a API do sistema operacional.

Quanto a isso, o QT é infinitamente melhor que o Swing. As diferenças sempre foram pequenas e, nas últimas versões, isso melhorou bastante.

Não creio que seja por isso. Já fiz aplicativos QT que ficaram muito leves.
Outros aplicativos famosos como Virtual Box, Skype, Maya, Mathematica, Adobe Photoshop Elements, também são feitos em QT.

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?

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.

victorcosta:

Eu não tenho experiência desktop fora Swing mas Qt pelo que leio na internet também não é a bala de prata pra todas as situações não

Em muitos casos ele é igual ao Swing, adicionando overhead por não usar controles nativos e também não simulando perfeitamente a aparência nativa, fora o tamanho do .exe

Dúvida que isso afete? Tenta escrever um concorrente do uTorrent (superleve) com ele e faça as pessoas usarem. Tenta concorrer com apps nativas no Mac onde o pessoal é bitolado pela aparência nativa

O VLC, player de vídeo q eu uso é feito em Qt e eu odeio o tempo de carregamento dele, mas não sei se a culpa é do Qt

Quanto aos wigets do qt e aparência nativa você tem razão, mas comparando com o swing o overhead dele é mínimo(para falar a verdade não dá para comparar). O kde é todo escrito nele e hoje é um dos desktops mais leves e com mais recursos para linux. O shell unity 2d do ubuntu é escrito nele.
O vlc junto com o mplayer são os players mais bem sucedidos do mundo opensource. A lentidão no carregamento é o tempo que ele leva para checar se hà updates. Os widgets são muito rápidos até porque o esquema de sinais e slots é o mais avançado dos toolkits gráficos.

http://doc.qt.nokia.com/4.7-snapshot/signalsandslots.html

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.

entanglement:

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.

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.

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

juliocbq:

entanglement:

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.

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.

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

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.

matheuslmota:

juliocbq:

entanglement:

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.

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.

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

É 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.

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:

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:

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.

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:

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 [email removido], envio o meu projeto de conclusão de curso que é em desktop, 7 jogos em java.

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 [email removido], envio o meu projeto de conclusão de curso que é em desktop, 7 jogos em java.

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.

juliocbq:

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 [email removido], envio o meu projeto de conclusão de curso que é em desktop, 7 jogos em java.

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.
.

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!!!

jmmenezes:

juliocbq:

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 [email removido], envio o meu projeto de conclusão de curso que é em desktop, 7 jogos em java.

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.
.

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…

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).

sergiotaborda:

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?

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.

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.

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.

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…

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#).

ViniGodoy:

Uma das coisas mais básicas em Desktop é também pegar o caminho onde a aplicação roda. Isso é trivial em várias linguagens, como C++ ou C#, mas é virtualmente impossível em Java.

Impossivel ?

File file = new File(".");

isto é equivalente a

File file = new File( System.getProperties("user.dir") + ".");

O user.dir indica de onde o executável java foi invocado. ( não confundir com user.home)

SecurityManager ? Ora, nem no servidor o povo usa isso… mas mesmo que use, é para isso que servem os arquivos de permissões.

A verdade é que não existe nenhuma razão para não usar java. Todos os pontos que vcs falaram são circunstanciais. Por exemplo, o fato de cada applicação rodar a sua JVM, é algo que é verdade hoje, mas não será verdade no futuro (existe previsão para o java 9 se não me engano).

luzales:

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.

é verdade! a maioria são desktop. mas são java?

sergiotaborda:

ViniGodoy:

Uma das coisas mais básicas em Desktop é também pegar o caminho onde a aplicação roda. Isso é trivial em várias linguagens, como C++ ou C#, mas é virtualmente impossível em Java.

Impossivel ?

File file = new File(".");

isto é equivalente a

File file = new File( System.getProperties("user.dir") + ".");

creio q o viny tava dizendo: “de onde foi executado o jar”;

e isso ai pode parecer ser, mas não é.

exemplo:

File file = new File(".");
System.out.println(file.getAbsolutePath());

System.setProperty( “user.dir”, “/teste/” );
System.out.println(file.getAbsolutePath());

saída:
D:\Java\Projetos\Testes.
\teste.

o jar será q mudou de lugar?
ou seja, ta se baseando no property “user.dir”, e não na localização do jar.

esse aki parece q funciona:

ClassLoader.getSystemClassLoader().getResource(".").getPath();

teria q testar.

Isso retorna o diretório de execução, que pode ser configurado no atalho do aplicativo, e que é diferente do diretório onde a aplicação está.

Isso retorna a User Folder, que é onde está a pasta “Meus documentos”.
E também é diferente do local onde o .jar está.

Algumas formas, como essa, quebram o galho, mas não tem formato de retorno consistente, nem funcionamento garantido em multiplataforma (o que é garantido é que irá retornar a raiz do seu class loader, não que isso necessariamente virá acompanhado do diretório onde o .jar está).

O que estou argumentando é que não existe um comando na plataforma que retorne essa informação. Se você vai fazer aplicações sérias, não pode se basear em comandos que “parece que funcionam”. Tem que ter um comando oficial, que a Oracle diga que tem faça o que você quer que faça.

Novamente, apela-se para a solução Eclipse. Cria-se um .exe que dispara sua aplicação com as opções certas da VM e, aproveitando o ensejo, já passe essa informação para o seu .jar. Entretanto, isso é um workaround para driblar uma deficiência que em outras plataformas você sequer teria.

PS: Eu não estou falando que seja ruim fazer aplicações corporativas Desktop em Java. Boa parte das aplicações não precisam do que falei. Se você for fazer seu sistema de controle de pizzaria®, então, pode usar Java tranquilo.

Ah! Acabei de lembrar de outros recursos em que o Java é capenga. Ele tem péssima integração com periféricos: Scanners, portas USB, porta serial/paralela, webcams ou controladores de jogo.

ViniGodoy:

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#).

Dá uma olhada no JavaFX. esses problemas que você apontou são reais e o pessoal da equipe de JavaFX está tentando limpar tudo isso.

Olha o FAQ do JavaFX:

Então, em breve Java Desktop será JavaFX.

Sobre os problemas de instalação, isso acaba em breve:

https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx

Mas outras coisas nativas ainda continuam complicadas e acredito que isso não muda tão cedo.

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.

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…

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…

O excelsior só vai otimizar o programa e não reduzir suas dependências. No final ele tem que embutir no executável a máquina virtual. Java é pesado porque tem muitas dependências. Quando digo “pesado” não quer dizer “lento”.

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.

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…

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…

O excelsior só vai otimizar o programa e não reduzir suas dependências. No final ele tem que embutir no executável a máquina virtual. Java é pesado porque tem muitas dependências. Quando digo “pesado” não quer dizer “lento”.

ah sim… mas pesado em tamanho… agora nos dias de hoje… algo em torno de 50mb é realmente pesado ???

Volto na questão… tudo depende do que você vai fazer… tem casos que Java realmente não é uma boa escolha… mas tem muitos casos onde Java Desktop é sim uma ótima pedida!

Será que vc sabe o que está fazendo ? Quem de posse das sua faculdades mentais iria querer mudar um system property ?
É pedir para ter problemas, e é isso exactamente que vc tem se tentar. Agora, vamos voltar ao assunto. Ele retornou “D:\Java\Projetos\Testes” quando vc leu a propriedade. Isso significa que ele sabe de onde foi iniciado e não, não é Meus Documentos (isso é o user.home)

do javadoc de File

Isto é muito util em programas de linha de comandos como o mvn do maven.
Sim, não diz onde está instalado o maven para é para isso que servem as configurações. No caso do maven e do ant e outros é preciso configurar o home. Isto porque eu posso querer mudar de versão conforme o projeto. Seria melhor que o java tivesse um caminho da instalação ? seria, mas ninguem tem isso. O caminho da instalação , como o nome indica, é criado durante a instalação. A instalação de um sistema desktop - quando bem feita - ou usa un instalador igual aos usados pelas outras plataformas, ou usa jws. Ou seja, alguem tém que escreve no maldito do registro do OS. E feito isso vc simplesmente usa o java.prefs para ler a pasta.

Dá para fazer com java o mesmo que se faz com os outros. É tudo uma questão de saber como e realmente explorar o desktop em java. As ferramentas estão todas lá.
A deficiencia não está na plataforma mas sim nos seus usuários que não a conhecem. Poderiamos argumentar que o java deveria vir com isso de fábrica ? podemos. Mas é impeditivo ? não. Porque qualquer programador consegue fazer direito com as ferramentas que ha.

Jesuino Master:

ViniGodoy:

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#).

Dá uma olhada no JavaFX. esses problemas que você apontou são reais e o pessoal da equipe de JavaFX está tentando limpar tudo isso.

Olha o FAQ do JavaFX:

Então, em breve Java Desktop será JavaFX.

Sobre os problemas de instalação, isso acaba em breve:

https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx

Mas outras coisas nativas ainda continuam complicadas e acredito que isso não muda tão cedo.

Isso vai quebrar um galhão para os desenvolvedores. O swing e swt são bons para criar sistemas solitários. Você usa só aquilo na máquina x. Não dá para fazer aplicativos que interagem com o sistema operacional e outras soluções, como criar menus de contexto e etc, Fora o peso que é completamente inviável para esse tipo de software. Com o javafx os desenvolvedores terão suporte a periféricos e sensores, api de desenho robusta, áudio e vídeo, tollkit de janelas leve(porque é nativo). Aí sim a coisa melhora bem.

Com certeza. Creio que no futuro ele se torne uma opção bem mais viável para desktop.

Mas achei que eles demoraram demais a priorizar isso, e estão entrando num mercado com anos luz de atraso. Para a tecnologia colar, vão ter muito trabalho, e precisarão de recursos realmente espetaculares.

Além disso, o inicio do JavaFX já queimou bastante o filme da tecnologia. Primeiro, a descrença pelas próprias demonstrações, na época da Sun, que eram penosamente lentas, mesmo em computadores relativamente top para a época. Depois, a demora em prover controles de UI, a indefinição do JavaFX Script (que acabou cortado).

Sei que muito disso está solucionado agora, mas creio que vão ter o mesmo trabalho que a MS está tendo com o SilverLight para limpar a bagunça que fizeram.

Além disso, boa parte dos recursos que o JavaFX oferece já está presente no QT na forma da QML há um bom tempo. A concorrência do Java já está fornecendo APIs assíncronas de alta qualidade (como as presentes no .Net 4.0 e no Flex), já tem frameworks maduros, fáceis de usar e consistentes e já não tinha todas essas deficiências. Por isso, é difícil alguém que trabalhe muito com desktop (como eu) considerar o Java hoje uma boa plataforma para esse tipo de ambiente.

Não que seja impossível fazer as coisas em Java, mas é que existem muitas alternativas onde você terá os mesmos recursos que Java oferece, sem os problemas.
Eu particularmente torço pelo Java. Gosto muito da linguagem, e seria legal ter a opção de usa-la em mais aplicações desktop ou em games.

sergiotaborda:

Isto é muito util em programas de linha de comandos como o mvn do maven.
Sim, não diz onde está instalado o maven para é para isso que servem as configurações. No caso do maven e do ant e outros é preciso configurar o home. Isto porque eu posso querer mudar de versão conforme o projeto. Seria melhor que o java tivesse um caminho da instalação ? seria, mas ninguem tem isso. O caminho da instalação , como o nome indica, é criado durante a instalação. A instalação de um sistema desktop - quando bem feita - ou usa un instalador igual aos usados pelas outras plataformas, ou usa jws. Ou seja, alguem tém que escreve no maldito do registro do OS. E feito isso vc simplesmente usa o java.prefs para ler a pasta.

Dá para fazer com java o mesmo que se faz com os outros. É tudo uma questão de saber como e realmente explorar o desktop em java. As ferramentas estão todas lá.
A deficiencia não está na plataforma mas sim nos seus usuários que não a conhecem. Poderiamos argumentar que o java deveria vir com isso de fábrica ? podemos. Mas é impeditivo ? não. Porque qualquer programador consegue fazer direito com as ferramentas que ha.

Quando se fala em aplicações desktop o diretório da aplicação é um diretório extremamente importante. Fico impressionado de no Java não ter como obter esse diretório.
E ele é diferente do diretório de execução da aplicação. No Java, as únicas opções são configurarem variáveis de ambiente, que são práticas para desenvolvedores, mas não para usuários, ou fazer o .exe mágico.

Em muitos sistemas operacionais, inclusive no Windows 8, o diretório da aplicação é um dos poucos onde a aplicação pode ler ou escrever. É também onde você pode colocar recursos que você gostaria que estivessem fora do .jar, tais como os plugins que o Eclipse tem, mods dos jogos ou scripts de seu usuário.

É claro que “dá para fazer” o que os outros fazem. Mas você sempre toma algum caminho tortuoso. Isso é o que chamamos de “workaround”, “jeitinho brasileiro” ou “xunxo”. É sempre melhor ter o recurso oficial, do que recorrer ao seu instalador gerar um arquivo em algum lugar que você conheça, gravar um variável de ambiente ou apelar para o JNI. Se estamos falando de uma plataforma ser ou não adequada a um tipo de solução, creio que estamos falando dela ser completa, não de termos que solicitar a outros programas, ou recorrer a bindings. Não estamos falando de ser “possível ou impossível”.

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.

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…

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…

O excelsior só vai otimizar o programa e não reduzir suas dependências. No final ele tem que embutir no executável a máquina virtual. Java é pesado porque tem muitas dependências. Quando digo “pesado” não quer dizer “lento”.

ah sim… mas pesado em tamanho… agora nos dias de hoje… algo em torno de 50mb é realmente pesado ???

Volto na questão… tudo depende do que você vai fazer… tem casos que Java realmente não é uma boa escolha… mas tem muitos casos onde Java Desktop é sim uma ótima pedida!

Concordo com você. Eu me refiro a “aplicativos” e não a programas específicos como erps, etc… Para isso acho o swing e o swt ótimos. O problema é o maldito peso da aplicação. Para você ter uma idéia, 50mb é o peso sozinho da classe principal do programa:

Um programa grande vai ocupar na faixa de 1gb ou mais de memória.

Por isso é difícil um desktop possuir mais de duas aplicações java rodando ao mesmo tempo. Um típico caso de desktop seria o seguinte:

Adobe Photoshop editando imagens e passando recursos pela área de transferência para o microsoft word, enquanto você escuta música com mediaplayer e surfa na internet.

Isso é impossível com o java que temos hoje, entendeu?

ViniGodoy:

PS: Eu não estou falando que seja ruim fazer aplicações corporativas Desktop em Java. Boa parte das aplicações não precisam do que falei. Se você for fazer seu sistema de controle de pizzaria®, então, pode usar Java tranquilo.

Ah! Acabei de lembrar de outros recursos em que o Java é capenga. Ele tem péssima integração com periféricos: Scanners, portas USB, porta serial/paralela, webcams ou controladores de jogo.

no guj só faltou um botão LIKE.
brincadeira , mas concordo com o que viny disse.

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.

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…

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…

O excelsior só vai otimizar o programa e não reduzir suas dependências. No final ele tem que embutir no executável a máquina virtual. Java é pesado porque tem muitas dependências. Quando digo “pesado” não quer dizer “lento”.

ah sim… mas pesado em tamanho… agora nos dias de hoje… algo em torno de 50mb é realmente pesado ???

Volto na questão… tudo depende do que você vai fazer… tem casos que Java realmente não é uma boa escolha… mas tem muitos casos onde Java Desktop é sim uma ótima pedida!

Concordo com você. Eu me refiro a “aplicativos” e não a programas específicos como erps, etc… Para isso acho o swing e o swt ótimos. O problema é o maldito peso da aplicação. Para você ter uma idéia, 50mb é o peso sozinho da classe principal do programa:

Um programa grande vai ocupar na faixa de 1gb ou mais de memória.

Por isso é difícil um desktop possuir mais de duas aplicações java rodando ao mesmo tempo. Um típico caso de desktop seria o seguinte:

Adobe Photoshop editando imagens e passando recursos pela área de transferência para o microsoft word, enquanto você escuta música com mediaplayer e surfa na internet.

Isso é impossível com o java que temos hoje, entendeu?

Sim… já tinha entendido… e Repito… eu dificilmente usaria Java para software de prateleira (entenda-se office, photoshop, games e coisas assim)…

No caso do corporativo, só não concordo em ser tão pesado assim… estou trabalhando atualmente em um sistema em SWT que possui 4000 classes java… e consultas muito pesadas que montam tabelas com mais de 100 mil registros numa unica tela… e dificilmente o consumo de memória deste programa passa de 100MB.
Não sei até que ponto conseguiria fazer tão melhor em .NET…
E os outros programadores da equipe nunca trabalharam em C++…

Sem dizer que 50% dos fontes são compartilhados com um módulo Web… aumentando a produtividade… e este que roda em linux (esse foi o principal motivo de descartarmos o .NET no inicio do projeto… a prova de conceito com o mono não foi satisfatória…

mas cada caso é um caso…

A maioria do que o Vini relatou, foi solucionada no JavaFX e no JDK 7, que consegue até usar directX 2D pra acelerar via hardware. Outros problemas já se resolvem com instaladores de forma automática pro desenvolvedor.

Pode até não ser a melhor solução para desenvolver um aplicativo desktop que suporte exclusivamente Windows, mas também não é um bixo de sete cabeças. E não corre o risco que as tecnologias MS correm: MFC era divulgado como o bambambam, agora todo mundo quer que morre porque era horrível. Antes disso já falaram o mesmo do Silverlight, COM/DCOM, COM+, Activex, … O que impede de um dia pro outro a Microsoft dizer que .NET não presta e que a melhor solulção é a .METRO, que vai revolucionar o mundo e fazer todos saírem de mãos dadas cantando “We are de world”? (não estou brincanco, assisti um evento da Microsoft nos Estados Unidos onde os desenvolvedores fizeram isso pra divulgar o .NET 1.0) :oops:

marcosalex:

A maioria do que o Vini relatou, foi solucionada no JavaFX e no JDK 7, que consegue até usar directX 2D pra acelerar via hardware. Outros problemas já se resolvem com instaladores de forma automática pro desenvolvedor.

Pode até não ser a melhor solução para desenvolver um aplicativo desktop que suporte exclusivamente Windows, mas também não é um bixo de sete cabeças. E não corre o risco que as tecnologias MS correm: MFC era divulgado como o bambambam, agora todo mundo quer que morre porque era horrível. Antes disso já falaram o mesmo do Silverlight, COM/DCOM, COM+, Activex, … O que impede de um dia pro outro a Microsoft dizer que .NET não presta e que a melhor solulção é a .METRO, que vai revolucionar o mundo e fazer todos saírem de mãos dadas cantando “We are de world”? (não estou brincanco, assisti um evento da Microsoft nos Estados Unidos onde os desenvolvedores fizeram isso pra divulgar o .NET 1.0) :oops:

Nesse ponto tenho de concordar… Java pode não ser “totalmente” software livre… mas não é vendor lockin! Não funciona só no windows! E é facil e barato ter multiplataforma com ele! (IMHO)

ViniGodoy:

É claro que “dá para fazer” o que os outros fazem. Mas você sempre toma algum caminho tortuoso. Isso é o que chamamos de “workaround”, “jeitinho brasileiro” ou “xunxo”. É sempre melhor ter o recurso oficial, do que recorrer ao seu instalador gerar um arquivo em algum lugar que você conheça, gravar um variável de ambiente ou apelar para o JNI. Se estamos falando de uma plataforma ser ou não adequada a um tipo de solução, creio que estamos falando dela ser completa, não de termos que solicitar a outros programas, ou recorrer a bindings. Não estamos falando de ser “possível ou impossível”.

Pera aí. Todas as aplicações windows usam o registry para dizer onde é a pasta da aplicação. Porque vc não quer fazer isso com java ?
O uso de exe não é para passar variáveis, isso vc pode fazer sem o exe. É para controlar a VM ( é um decorator da VM, não da aplicação).
Ok que passar -Xmx tem que ser feito por fora, mas isso é porque não é um comando padrão de todas as VM. É por isso que não está mais integrado. Ha que lembrar que o java é multiplataforma e existem várias VM. Ao contrario do .net ou do C++.

Usar o registry não é um workarround é o que todos fazem. É o padrão certo ( padrão Registry). É o mesmo que o uso de JNDI no EE. Sem JNI.
Se o cara desenvolve desktop e precisa de configruar o OS mas não distribui usando um instalador é o cara que se está auto sabotando.
O java.prefs serve exactamente para isto. Para vc guarda informações da aplicação e deixar a JVM se preocupar onde guardar os dados. Qualquer coisa fora disso não é uso padrão e como tal, não tem regra padrão ( por exemplo, guarda logs)

Agora eu fiquei curiso para saber como o .net , o C, etc sabem onde a aplicação está. Até onde eu sei C envia o caminho de execução no primeiro argumento do args e o .net faz o mesmo que o java dando acesso apenas a onde foi executado o exe (Application.executablePath) e todas as pastas de dados ele cria dentro do home do usuario (que é onde o usuário tem permissão). É o mesmo processo.
Aqui também é necessário o Registry se quiser saber onde está o exe. Não ?

O ponto é, se todos fazer assim, porque criticar o java por fazer igual ?

O swt já é um toolkit nativo, então o programa já carrega menos dependências que no swing. Para software corporativo java na minha opinião é uma alternativa até mais adequada que dotnet. Pela portabilidade e flexibilidade como citaram acima. O problema do dotnet é ser fechado no windows, mesmo tendo alternativas como o mono, que você teria que se ater ao c# 3 e winforms 2.

sergiotaborda:

Será que vc sabe o que está fazendo ? Quem de posse das sua faculdades mentais iria querer mudar um system property ?
É pedir para ter problemas, e é isso exactamente que vc tem se tentar. Agora, vamos voltar ao assunto. Ele retornou "D:\Java\Projetos\Testes" quando vc leu a propriedade. Isso significa que ele sabe de onde foi iniciado e não, não é Meus Documentos (isso é o user.home) .

só quis mostrar q a informação não era o q vc tava dizendo q era.

mas, uma pergunta:

public class Teste { public static void main(String[] args) { System.out.println(System.getProperty( "user.dir")); } }

gerar o Teste.jar;

colocar o Teste.jar no c:\teste\

no prompt de comando:

>cd %public%\desktop
>java -jar c:\teste\teste.jar

pq imprimiu:
C:\Users\Public\Desktop

???

o registry pra saber onde está o .exe? como assim?

pera ai! pra dizer, ou pra saber?

GilsonNunes:

sergiotaborda:

Será que vc sabe o que está fazendo ? Quem de posse das sua faculdades mentais iria querer mudar um system property ?
É pedir para ter problemas, e é isso exactamente que vc tem se tentar. Agora, vamos voltar ao assunto. Ele retornou "D:\Java\Projetos\Testes" quando vc leu a propriedade. Isso significa que ele sabe de onde foi iniciado e não, não é Meus Documentos (isso é o user.home) .

só quis mostrar q a informação não era o q vc tava dizendo q era.

mas, uma pergunta:

public class Teste { public static void main(String[] args) { System.out.println(System.getProperty( "user.dir")); } }

gerar o Teste.jar;

colocar o Teste.jar no c:\teste\

no prompt de comando:

>cd %public%\desktop
>java -jar c:\teste\teste.jar

pq imprimiu:
C:\Users\Public\Desktop

???

Porque não é isso que ele vai imprimir. Ele vai imprimir a pasta de onde vc invocou o java (que foi C:\Users\Public\Desktop).
E como eu já disse , isso é util para ferramentas de linha de comandos. Para desktop vc simplesmente força chamar da pasta certa (usando o exe que o vini falou) ou simples usa o registro do OS que é a forma mais simples. Seja de onde for que vc chamar o registro sempre apontará o mesmo lugar.

Eu havia entendido que estava sendo dito que o java não tinha como saber de onde foi invocado. O user.dir dá essa informação.
Só que o argumento do Vini é que não havia como saber a pasta onde a aplicação está ( onde está o jar). Existem formar no java de fazer isso, mas como o foi dito não são “padrão”. Ou melhor, são usos da API que produzem o resultado certo que o Viny chamou de workarround. (Hoje em dia qualquer motor de injeção faz um workarround para pesquisar as classes que existem no path para depois pesquisar anotações e ninguém diz que o java não dá suporte). O ponto é que a API não tem um método simples e obriga vc a conhecer muito de java de como funciona o modelo de classloading.

O que eu argumentei então é que neste caso em que vc quer saber o caminho da pasta da aplicação, a única opção é usar o registro do OS via java.prefs e um instalador - da mesma forma que os jogos e outros aplicativos fazem. Este caminho realmente o java não lhe de mão beijada - embora possa ser descoberto como já disse - e o argumento é que outras plataformas oferecem essa informação de forma simples e que isso faz toda a diferença.

O que eu estou dizendo é que não faz diferença nenhuma. Vc pode usar as mesmas tecnicas em java que usa nos outros.

Não? Em materia de tecnologia para Desktop, o Java não está atrás.

Começou com a AWT… que logo foi abandonada. Swing era o bambambam, ficou na geladeira por alguns meses (para não dizer alguns anos)… e agora temos que ir para o JavaFX.
O JavaFX Script era a solução, foi abandonado. Tinhamos o Java 3D também, que foi abandonado. Não podemos esquecer da comunicação serial, cujo suporte ao Windows foi silenciosamente retirado, e que foi abandonado. A java.sound, que começou bem, ficou uma API legal, mas o desenvolvimento foi abandonado, sem suporte a vários e vários arquivos comuns de áudio. Ah sim, faltou a JMF, que veio prometendo webcam, e foi abandonada.

E as APIs de USB, controles e outros devices, que nunca existiram…

Viajou Sérgio? O caminho da aplicação é o primeiro parâmetro do args das aplicações C++.
E existe uma função do Windows, do Metro e do Linux para pegar essa informação, sem recorrer ao registro.

Sim, mas a questão não é essa. Nos outros, vc não precisa dessa gambi toda. A informação está simplesmente lá.

Faz mesmo. Mas existem empresas por trás desses motores, que estão garantindo isso para você. E garantindo seu funcionamento multiplataforma.
Se não me engano, eles também se baseiam na estrutura do .jar e de classes, coisas que são padronizadas e não devem mudar.

É bem diferente de você testar um método, sem quase critério nenhum, e inserir isso na sua aplicação. O próprio do classloader mesmo, não há nada na especificação que garanta minimamente o formato e o tipo de informação que o getPath() de um classloader vá te retornar.

A única coisa que ele garante é que será o mesmo path que o classloader padrão usará para saber onde está o recurso. E ali, pode ou não haver o caminho exato do .jar no SO.

De qualquer forma, essa é um dos vários problemas que citei.

Eu acho que não estou viajando. O primeiro argumento do C++ é o caminho de invocação (equivalente ao user.dir)
Para pegar o caminho do executável (onde o exe está) não é trivial e não vem pronto. E segundo o link, nem o args[0] é confiável.

Não sei. Não uso C++. Mas não encontrei referencia a essa facilidade “out-of-the-box”.
Então talvez apenas o .net tenha isso “out-of-the-box”. Mas qual é a função ? Eu não encontrei a referencia.

sergiotaborda:

Eu acho que não estou viajando. O primeiro argumento do C++ é o caminho de invocação (equivalente ao user.dir)
Para pegar o caminho do executável (onde o exe está) não é trivial e não vem pronto. E segundo o link, nem o args[0] é confiável.

Não sei. Não uso C++. Mas não encontrei referencia a essa facilidade “out-of-the-box”.
Então talvez apenas o .net tenha isso “out-of-the-box”. Mas qual é a função ? Eu não encontrei a referencia.

Tem razão, basta chamar duas funções:
For Linux: readlink /proc/self/exe
Windows: GetModuleFileName

E isso é trivialmente invocado do C++ (já que ele não te promete multiplataforma).

Anyway, pode ser que eu esteja errado nesse quesito. Em todo caso, esse é um dos pontos que citei, os outros, que são até mais relevantes, ainda continuam válidos.

Como eu suspeitava, você está enganado, veja o que diz o standard:

A única coisa que o Standard ressalta é que esse caminho pode não existir caso o host não tenha essa informação. É o caso de você executar o C através de um terminal, por exemplo. Eu, particularmente, nunca vi o comando falhar. E, de qualquer forma, o padrão é claro ao dizer que ele retorna o program name - e é consenso nas implementações C que esse nome se refere ao “full qualified path”.

De qualquer forma, como ressaltei, é bem fácil para um programador C usar a função específica do SO.
Essa integração é uma das propostas da linguagem.

Talvez não. Aliás, não é raro ainda vermos softwares comerciais escritos em Delphi ou Visual Basic. Grande parte dos desenvolvedores maduros de software desktop são órfãos do Delphi ou Visual Basic e migraram naturalmente para o C#/Visual Studio. É verdade também que o ambiente desktop nunca foi a prioridade do Java, basta ver os anos de descaso com o Swing. Felizmente o ressurgimento do JavaFX está buscando mudar essa realidade.
Mas de qualquer forma, eu estava me referindo a velha discussão se vale a pena aprender programar para desktop. Para mim acho que software desktop não vai morrer tão cedo e ainda há um nicho de mercado ativo.
Creio que grande parte dos problemas levantados em relação ao Java podem ser contornados ou não são significativos para grande parte das situações. Por exemplo, que mal tem utilizar um instalador para resolver questões de empacotamento e deploy? É claro que nenhuma tecnologia é mágica e haverá situações específicas em que talvez o Java não seja a melhor escolha. Isso não é demérito da plataforma.
Bom, se Java não fosse viável para desktop o Netbeans e Eclipse não seriam escritos nessa linguagem, as maiores referências de softwares desktop desenvolvidos em Java.
Particularmente também estou bastante otimista em relação ao JavaFX e aposto no seu amadurecimento para consolidar a viabilidade do Java em aplicações desktop, tanto melhorando questões de design de interface quanto performance e gerenciamento de memória.

Mas o melhor de tudo é ver o quanto de conhecimento foi difundido em decorrência da dúvida inicial. No final das contas a discussão virou uma “briga de cachorro grande”, um “duelo de titãs” entre o vini e o sergiotaborda, rsrs. Isso engrandece o fórum e gera conhecimento.

Como eu suspeitava, você está enganado, veja o que diz o standard:

A única coisa que o Standard ressalta é que esse caminho pode não existir caso o host não tenha essa informação. É o caso de você executar o C através de um terminal, por exemplo. Eu, particularmente, nunca vi o comando falhar. E, de qualquer forma, o padrão é claro ao dizer que ele retorna o program name - e é consenso nas implementações C que esse nome se refere ao “full qualified path”.

De qualquer forma, como ressaltei, é bem fácil para um programador C usar a função específica do SO.
Essa integração é uma das propostas da linguagem.

quem usa LCL/fpc mesmo, apenas faz assim:

s := Application.ExeName;

isso independente de ser nos win32, win64, linuxAll, winCe, macOS, solaris, OS2, etc.

Eu mesmo fui programador de Delphi, VB5, VB6 e Visual C++ Builder (e antes disso de Clipper e Pascal, mas aí estamos indo longe demais o Tunel do Tempo).

Mas de qualquer forma, eu estava me referindo a velha discussão se vale a pena aprender programar para desktop. Para mim acho que software desktop não vai morrer tão cedo e ainda há um nicho de mercado ativo.

Com certeza. Eu mesmo estou no mercado desktop há muitos anos (se vcs não notaram, eu raramente apareço nos tópicos de desenvolvimento web), e não vejo ele desacelerar.
Aliás, até pelo contrário. A introdução do Metro e dos dispositivos móveis deu foi um boom no mercado (apps. para dispositivos móveis são aplicações desktop).
A web também abriu portas para a distribuição de aplicações, coisa que na época em que só havia apps desktop por aí, não tinhamos (você até podia fazer o software, mas muitas vezes jamais conseguiria distribui-lo para um grande mercado sem um publisher).

Há certas indústrias, como as de engenharia, onde sequer faz sentido falar em aplicações web. Aplicativos que são usados para controlar dispositivos ou tomar decisões em tempo real.
Sem falar nos aplicativos “de prateleira”, para o usuário de PC.

A grande vantagem é que as tecnologias Desktop e web estão se aproximando. No Windows 8, por exemplo, já vai ser possível programar usando HTML 5 e Javascript para criar suas telas. No caso do QT e do próprio JavaFX, linguagens como a QML e o Groovy tornam o código bastante declarativo, bem similar ao que um desenvolvedor web já encontra. Do outro lado, a web também torna-se cada vez mais responsiva, o javascript cada vez mais poderoso e mais e mais idiomas de desktop vão sendo incorporados as páginas.

Creio que grande parte dos problemas levantados em relação ao Java podem ser contornados ou não são significativos para grande parte das situações. Por exemplo, que mal tem utilizar um instalador para resolver questões de empacotamento e deploy?

É claro que nenhuma tecnologia é mágica e haverá situações específicas em que talvez o Java não seja a melhor escolha. Isso não é demérito da plataforma.
Bom, se Java não fosse viável para desktop o Netbeans e Eclipse não seriam escritos nessa linguagem, as maiores referências de softwares desktop desenvolvidos em Java.

O Eclipse não é feito inteiramente na plataforma Java. Ele depende da SWT, que usa JNI. É claro que o SWT é confiável e maduro, mas não é Java padrão (não dá para usa-lo para defender a plataforma, pois roda fora da VM).
No caso, podemos citar como apps desktop o Netbeans, o MySQL Workbench e o Vuze. Ainda assim, dois deles são apps para desenvolvedores. Dá para contar no dedos quantos aplicativos desktop de mercado famosos usando somente a plataforma Java temos por aí (além do Vuze, alguém conhece mais algum?). Agora, não significa que seja impossível, ou mesmo inviável, desenvolver aplicações corporativas em Java desktop. Note que eu fui cuidadoso, desde o primeiro post, ao falar que estava falando do mercado de aplicações para consumidores, e não empresas.

Basta ver como exemplo softwares de SAP, que são em Java. Na Siemens mesmo, utilizei Java por vários anos com muito sucesso (embora tenha sofrido um pouco com a descontinuação repentina da javax.comm). Eu gosto de usar o Java para desktop em meus estudos também, como é o caso desse editor de imagens, que fiz para o mestrado.

Vale lembrar que, mesmo fora da plataforma Java, temos frameworks maduros e garantidos, como a SWT, RXTX, DirectShowJava, Javacv e a LWJGL. É através deles que surgiram não só o Eclipse, mas o Minecraft, Taikodom e outros aplicativos conhecidos. Não vejo problema em usa-los, pois são muito bons. Só estou gostaria de fazer aqui a diferenciação entre “conseguir fazer aplicações usando linguagens Java” e “defender o Java como plataforma para desktop”. Usando a linguagem Java, você consegue fazer muita coisa, pois pode recorrer a bindings como esses que rodam fora da plataforma e resolvem o problema. Já na plataforma java, mantida pela Oracle, e garantida em todas as VMs java padrão, a coisa aperta.

O fato é que, na minha opinião, os problemas, são sim, demérito para a plataforma (no quesito desktop). Eu acho engraçado que nós vivemos ouvindo no GUJ que “linguagens são ferramentas e o programador tem que se adaptar a cada caso”. Essa frase rola por aqui pelo menos uma vez por semana. Mas chega um tópico desses, onde o Java claramente não é a melhor ferramenta, e o pessoal defende a plataforma com unhas e dentes. É a mesma coisa em tópicos sobre games.

Se falarmos em defender a plataforma como um todo, as coisas são bem diferentes, por exemplo, ao fazer apps usando a plataforma Android, mesmo que usando linguagem Java.
Ele não só nasceu para isso, como a Google tomou bastante cuidado, associando poder, facilidade de implementação e conceitos modernos de programação desktop.

Como fã da linguagem, e da plataforma Java como um todo, é o que eu torço também.

Exatamente! Argumento imbatível contra os céticos do mercado desktop.

Show de bola o DirectShowJava. Eu ainda não tinha conhecido esse framework. No site do projeto inclusive é uma demo demonstrando a integração do framework com JavaFX.

É verdade, às vezes o entusiasmo pela linguagem impede de enxergamos as deficiências técnicas da plataforma. Reconheço que é temerário defender uma linguagem/plataforma com unas e dentes, rs.

Fruto de um planejamento meticuloso, focado e com objetivos bem definidos. Algo que não esteve presente no tradicional Java Desktop, basta vermos a evolução “tartaruga” do Swing.

Somos dois.

Resumiu tudo com chave de ouro, rsrs.
PS: Muito interessante seu editor de imagens.

Todas essas APIs estão nas versões superiores do Java, inclusive no beta da JDK8. Sem mais.

Acontece que no seu post original você não estava falando de estar ou não presente no JDK, ou em retrocompatibilidade.
Mas no fato do pessoal falar que a tecnologia anterior é horrível, pedir para ela morrer e usar outra no lugar.

No caso da Sun, algumas pediram para morrer e nem sequer colocaram outras no lugar (Java3D, javax.comm).
Na minha opinião, o posicionamento foi até pior, pois foram silenciosamente abandonadas, sem maiores satisfações a comunidade, ou sem aviso.

E, no caso do ambiente de janelas, ocorreu a mesma coisa que ocorre com a MS (AWT->Swing->JavaFX).
Mas daí com anuncio oficial.

Quanto a retrocompatibilidade, aí até concordo com você. A MS tem mania mesmo de não garantir isso direito.
No .Net até tem feito um bom trabalho, mas não ponho minha mão no fogo por eles (aliás, o WinForms vai mesmo ser substituido pelas APIs metro).

Vini, só uma correção. Até onde eu sei, atualmente o MySQL Workbench é escrito usando alguma linguagem da plataforma .Net (provavelmente C#) e usa Python internamente. Não sei se você comentou sobre alguma versão antiga ou se estou desatualizado e mudaram isso recentemente.

[]'s

davidbuzatto:

Vini, só uma correção. Até onde eu sei, atualmente o MySQL Workbench é escrito usando alguma linguagem da plataforma .Net (provavelmente C#) e usa Python internamente. Não sei se você comentou sobre alguma versão antiga ou se estou desatualizado e mudaram isso recentemente.

Acho que me confundi mesmo.

Acontece que no seu post original você não estava falando de estar ou não presente no JDK, ou em retrocompatibilidade.
Mas no fato do pessoal falar que a tecnologia anterior é horrível, pedir para ela morrer e usar outra no lugar.

No caso da Sun, algumas pediram para morrer e nem sequer colocaram outras no lugar (Java3D, javax.comm).
Na minha opinião, o posicionamento foi até pior, pois foram silenciosamente abandonadas, sem maiores satisfações a comunidade, ou sem aviso.

E, no caso do ambiente de janelas, ocorreu a mesma coisa que ocorre com a MS (AWT->Swing->JavaFX).
Mas daí com anuncio oficial.

Quanto a retrocompatibilidade, aí até concordo com você. A MS tem mania mesmo de não garantir isso direito.
No .Net até tem feito um bom trabalho, mas não ponho minha mão no fogo por eles (aliás, o WinForms vai mesmo ser substituido pelas APIs metro).

Grande vini e marcão, a MS tah amarrada e desde o Vista prometeram um monte mas, uma apostinha mudança soh perfumaria.

Eu trabalho com Java para Desktop e simplesmente não acho perca de tempo, pois é uma linguagem muito flexivel.
Sabemos Java para Web é muito mais utilizada, mas Java para desktop te dá uma boa base para entender a linguagem, se você é iniciante.

Java pra mim continua sendo a melhor.

Aldeir:

Eu trabalho com Java para Desktop e simplesmente não acho perca de tempo, pois é uma linguagem muito flexivel.
Sabemos Java para Web é muito mais utilizada, mas Java para desktop te dá uma boa base para entender a linguagem, se você é iniciante.

Java pra mim continua sendo a melhor.

Não podemos esquecer dos velhos aplicativos para frente de caixa, controle de estoque, etc
que dificilmente sairão do mercado.
Sistemas ERP’s, enfim varias aplicações ainda poderão continuar sendo desenvolvidas com Java para desktop.

Aldeir:

Não podemos esquecer dos velhos aplicativos para frente de caixa, controle de estoque, etc
que dificilmente sairão do mercado.
Sistemas ERP’s, enfim varias aplicações ainda poderão continuar sendo desenvolvidas com Java para desktop.

Sistemas de automação comercial são difíceis de serem produzidos em Java, já que quase sempre é necessário comunicação via porta serial / porta paralela com dispositivos como leitora de código de barra, máquinas de frente de caixa etc. e o suporte a tais dispositivos é muito pobre em Java.
Sem falar que quando se precisa ter acesso à uma máquina de frente de caixa, como a da Bematech, é necessário fazer o uso de alguma DLL que não foi projetada para ser usada com Java e isso é uma fonte de dores de cabeça.

Sim, quanto a isso concordo com você. Citei apenas como exemplo.
Quanto aos equipamentos da Bematech, eles dão sim ferramentas de apoio, inclusive emuladores desses equipamentos, para você testar suas aplicações, mas concordo com a dor de cabeça.
Recentemente fiz uma aplicação para um cliente que queria usar para impressoras matriciais, foi um pé no saco, mas deu certo.

Talvez eu esteja puxando a sardinha para Java porque realmente adoro a linguagem, e não sou muito fã das tecnologias da Microsoft, como por exemplo a linguagem C#, mas concordo que também é uma linguagem espetacular.

Citei C# somente como comparativo.

Aldeir:

Sim, quanto a isso concordo com você. Citei apenas como exemplo.
Quanto aos equipamentos da Bematech, eles dão sim ferramentas de apoio, inclusive emuladores desses equipamentos, para você testar suas aplicações, mas concordo com a dor de cabeça.
Recentemente fiz uma aplicação para um cliente que queria usar para impressoras matriciais, foi um pé no saco, mas deu certo.

Talvez eu esteja puxando a sardinha para Java porque realmente adoro a linguagem, e não sou muito fã das tecnologias da Microsoft, como por exemplo a linguagem C#, mas concordo que também é uma linguagem espetacular.

Citei C# somente como comparativo.

Para sistemas corporativos java é uma ótima opção sim(tanto desktop como web). O debate do pessoal acima se refere ao cenário desktop em que você iterage entre várias aplicações simultâneamente. Isso fica ruim com java.

Imagina se o seu office, photoshop, media player, browser, gerenciador de arquivos fossem escritos em java? Ia precisar de um servidor para ser usado como máquina de usuário para rodar isso de maneira adequada(com fluidez).

Tem gente aí que fala que é preconceito. Isso não tem nada a ver. É só um caso de uso que a java(plataforma) não resolve o problema de maneira adequada.

Java é pesadão mesmo. Da mesma forma que a Microsoft não redesenvolveu o MS Office em .NET, apesar de no começo ter anunciado que faria isso. Lembro que os primeiros beta do Windows Vista tinha muita coisa em .NET e a cada novo beta o númeor de código .NET diminuiu. Isso foi muito discutido na época e a MS justificou que a plataforma ainda estava amadurecendo.

Eu mesmo fui programador de Delphi, VB5, VB6 e Visual C++ Builder (e antes disso de Clipper e Pascal, mas aí estamos indo longe demais o Tunel do Tempo).

Mas de qualquer forma, eu estava me referindo a velha discussão se vale a pena aprender programar para desktop. Para mim acho que software desktop não vai morrer tão cedo e ainda há um nicho de mercado ativo.

Com certeza. Eu mesmo estou no mercado desktop há muitos anos (se vcs não notaram, eu raramente apareço nos tópicos de desenvolvimento web), e não vejo ele desacelerar.
Aliás, até pelo contrário. A introdução do Metro e dos dispositivos móveis deu foi um boom no mercado (apps. para dispositivos móveis são aplicações desktop).
A web também abriu portas para a distribuição de aplicações, coisa que na época em que só havia apps desktop por aí, não tinhamos (você até podia fazer o software, mas muitas vezes jamais conseguiria distribui-lo para um grande mercado sem um publisher).

Há certas indústrias, como as de engenharia, onde sequer faz sentido falar em aplicações web. Aplicativos que são usados para controlar dispositivos ou tomar decisões em tempo real.
Sem falar nos aplicativos “de prateleira”, para o usuário de PC.

A grande vantagem é que as tecnologias Desktop e web estão se aproximando. No Windows 8, por exemplo, já vai ser possível programar usando HTML 5 e Javascript para criar suas telas. No caso do QT e do próprio JavaFX, linguagens como a QML e o Groovy tornam o código bastante declarativo, bem similar ao que um desenvolvedor web já encontra. Do outro lado, a web também torna-se cada vez mais responsiva, o javascript cada vez mais poderoso e mais e mais idiomas de desktop vão sendo incorporados as páginas.

Creio que grande parte dos problemas levantados em relação ao Java podem ser contornados ou não são significativos para grande parte das situações. Por exemplo, que mal tem utilizar um instalador para resolver questões de empacotamento e deploy?

É claro que nenhuma tecnologia é mágica e haverá situações específicas em que talvez o Java não seja a melhor escolha. Isso não é demérito da plataforma.
Bom, se Java não fosse viável para desktop o Netbeans e Eclipse não seriam escritos nessa linguagem, as maiores referências de softwares desktop desenvolvidos em Java.

O Eclipse não é feito inteiramente na plataforma Java. Ele depende da SWT, que usa JNI. É claro que o SWT é confiável e maduro, mas não é Java padrão (não dá para usa-lo para defender a plataforma, pois roda fora da VM).
No caso, podemos citar como apps desktop o Netbeans, o MySQL Workbench e o Vuze. Ainda assim, dois deles são apps para desenvolvedores. Dá para contar no dedos quantos aplicativos desktop de mercado famosos usando somente a plataforma Java temos por aí (além do Vuze, alguém conhece mais algum?). Agora, não significa que seja impossível, ou mesmo inviável, desenvolver aplicações corporativas em Java desktop. Note que eu fui cuidadoso, desde o primeiro post, ao falar que estava falando do mercado de aplicações para consumidores, e não empresas.

Basta ver como exemplo softwares de SAP, que são em Java. Na Siemens mesmo, utilizei Java por vários anos com muito sucesso (embora tenha sofrido um pouco com a descontinuação repentina da javax.comm). Eu gosto de usar o Java para desktop em meus estudos também, como é o caso desse editor de imagens, que fiz para o mestrado.

Vale lembrar que, mesmo fora da plataforma Java, temos frameworks maduros e garantidos, como a SWT, RXTX, DirectShowJava, Javacv e a LWJGL. É através deles que surgiram não só o Eclipse, mas o Minecraft, Taikodom e outros aplicativos conhecidos. Não vejo problema em usa-los, pois são muito bons. Só estou gostaria de fazer aqui a diferenciação entre “conseguir fazer aplicações usando linguagens Java” e “defender o Java como plataforma para desktop”. Usando a linguagem Java, você consegue fazer muita coisa, pois pode recorrer a bindings como esses que rodam fora da plataforma e resolvem o problema. Já na plataforma java, mantida pela Oracle, e garantida em todas as VMs java padrão, a coisa aperta.

O fato é que, na minha opinião, os problemas, são sim, demérito para a plataforma (no quesito desktop). Eu acho engraçado que nós vivemos ouvindo no GUJ que “linguagens são ferramentas e o programador tem que se adaptar a cada caso”. Essa frase rola por aqui pelo menos uma vez por semana. Mas chega um tópico desses, onde o Java claramente não é a melhor ferramenta, e o pessoal defende a plataforma com unhas e dentes. É a mesma coisa em tópicos sobre games.

Se falarmos em defender a plataforma como um todo, as coisas são bem diferentes, por exemplo, ao fazer apps usando a plataforma Android, mesmo que usando linguagem Java.
Ele não só nasceu para isso, como a Google tomou bastante cuidado, associando poder, facilidade de implementação e conceitos modernos de programação desktop.

Como fã da linguagem, e da plataforma Java como um todo, é o que eu torço também. :)

Vini… o Vuze usa SWT… Já teve outro tópico que falamos sobre apps. java e lembro de termos chegado a conclusão (pelo menos a maioria) que não existe nada muito grande desktop que seja tudo com a plataforma Java… e sim a maior parte das coisas grandes desktop estão na linguagem Java usando bind para outras coisas.

PS: Gostei do editor de imagem!