Olá!
Eu decidi postar este tópico porque eu gostaria de saber se é realmente fato que Java é uma tecnologia morta para Desktop ou se ainda são desenvolvidos grandes projetos em Java para o Desktop.
O Java para desktop é uma tecnologia morta?
Legado não, mas novos projetos sim. Java em novos projetos é mais para backend.
No geral o próprio desktop está morto pra maioria dos casos de sistemas de informações. Exceto “ferramentas” desktop e módulos mais específicos que dependem de acesso avançado ao hardware.
Maioria das novas ferramentas desktop são feitas em JS com Electron. E C++ pra softwares desktop mais complexos (a exemplo de algo do nível do Photoshop).
4 curtidas
Creio que não, eu pelo menos ja vi varias linguagens de programação que dizem morreu, e de uma hora para outra surge alguem usando em um grande projeto, é o caso do Delphi, varias aplicações ainda são feitas em Delphi e estao sendo feitas, no caso do java conheço varios sistemas desktop de grandes empresas, e ainda utilizam swing tendo o javafx ae, no fundo acho que uma linguagem so morre quando as pessoas param de usar, o resto so o tempo para dizer, a verdade é que o java independente da plataforma ele ainda é uma poderosa linguagem.
2 curtidas
Acho difícil generalizar. Vai depender muito dos requisitos, do caso de uso. Em primeiro lugar as aplicações desktop em si, independente da linguagem, não estão mortas, há casos para web e casos para desktop, como IDEs, editores de mídias, aplicações que integram com hardware local (impressoras térmicas, etc). Quando as tecnologias web surgiram muitas coisas que antes eram feitas em desktop, como ERPs, foi vantajoso fazer em web, acho que foi isso que o @javaflex quis dizer. Porém o navegador não é nem pode ser o sistema operacional, seria acesso privilegiado demais ao hardware. Então acho importante diferenciar o que está “morto” do que é usado mas não é mainstream, como ferramentas.
A escolha do Java pode fazer sentido em alguns casos, por exemplo pela ampla disponibilidade de bibliotecas, o que outras linguagens vêm alcançando em graus variados, ou pelo conhecimento prévio da equipe disponível na tecnologia, que costuma ser um fator importante. Duas desvantagens são depender de JVM instalada e tentar impor uma GUI padronizada para todos os sistemas operacionais que não é a experiência de usuário daquele sistema operacional, se bem que web e Electron também fazem isso. Para muitos isso não é problema mas para alguns é.
Ainda no caso do Electron, não acompanho outros lançamentos para constatar essa afirmação que “a maioria das ferramentas é lançada em Electron”, só o VS Code, que é surpreendentemente pouco pesado (pero no mucho). O IntelliJ IDEA que é um IDE de relevância nesse cenário que eu saiba não é feito em Electron.
A premissa do Electron em si eu acho problemática: embutir todo um navegador ou motor de navegação numa aplicação desktop e usufruir da padronização e recursos da programação web. Isso traz duas consequências em princípio, o executável incha e fica bem maior do que poderia ser, e o consumo de memória da aplicação fica bem maior (não que Java não consuma também, mas pelo menos não o faz por conta de coisas supérfluas).
Em tempos que o pessoal tem desaprendido e parado de considerar fazer otimizações no código porque o hardware tem dado conta de aplicações mais exigentes, não vejo com bons olhos essa abordagem do Electron. Não dá pra dizer que é o “futuro”. É só uma das formas de fazer, e provavelmente não das melhores.
Dito isso, o VS Code é uma ótima ferramenta pelo pouco que usei, e não é pesada para abrir projetos (para abrir um arquivo individual já não sei). Ouvi falar que eles trouxeram um bam-bam-bam do Eclipse (que está vivo e bem, assim como Linux desktop tem um market share pequeno e mesmo assim está vivo e bem) para coordenar o desenvolvimento, por isso deslanchou. Não sei se é verdade.
O pessoal vê sair do mainstream e já anuncia a morte, aqui no fórum mesmo não é a primeira vez que a morte do Java e do desktop foram anunciadas. 
De forma alguma.
Java continua mais forte que nunca.
Evolução constante no JavaFX.
Possibilidade de usar modularização que reduz o tempo de carregamento e melhor uso da memoria, a velha e atual segurança de sempre cada vez melhor e uma enorme comunidade de desenvolvedores.
Diziam alguns e ainda dizem que é absurdo querer usar Java em tudo ou praticamente tudo, absurdo mesmo é usar JavaScript em tudo ou praticamente tudo.
Sua equipe vai chorar na hora de dar manutenção em JavaScript.
Plataforma Electron falta segurança e é um ridículo ter que colocar um simples “Ola Mundo” dentro de um navegador.
Java evoluiu e continua evoluindo, alem da modularização da pra gerar nativo com http://www.graalvm.org, mantendo a segurança de sempre do Java.
1 curtida
Várias aplicações desktop construídas na atualidade e usadas por muitos no dia a dia são feitas em Electron, apenas alguns fatos:
VS Code
Discord
Atom
GitHub Desktop
Slack
WhatsApp Desktop
Skype
Postman
Teams
Java está morto para novas aplicações desktop, não para novas aplicações web. Claro que nada impede de você estar na minoria que ainda vive de passado e escolhe Java para novas aplicações desktop.
Calma, não precisa dizer que vivo no passado (ou você está respondendo o j-menezes?). Só apresentei alguns argumentos que podem pesar na escolha. Moderno não quer dizer sempre bom. Flash já foi moderno. SSD é melhor que HD mas tem limitação de reescritas, para fazer swap dependendo da demanda pode prejudicar a vida útil do armazenamento. E NoSQL nunca substituiu o bom e velho relacional dos anos 60. Java ficou um tempo para trás na mão da Oracle e retomou o passo já há algum tempo, tem um longo futuro ainda, é uma tecnologia calcada em mais decisões certas que erradas e isso tem peso na evolução da tecnologia. Em termos de GUI o Java Swing não é moderno mas é estabelecido e documentado, pode interessar em algumas situações (se não interessar minha segunda opção a princípio não seria o Electron; provavelmente seria C#, se não considerasse equipe e caso de uso, só pelo ecossistema e recursos), e o JavaFX eu entendo como uma evolução a ser considerada dependendo do caso. JavaScript apesar de ter adoção ubíqua por causa dos navegadores é uma linguagem cuja base foi criada em duas semanas (tá bom, é uma mágoa pessoal rs). Não estou dizendo que não deva ser aprendida e utilizada. Tem que pesar vantagens e desvantagens para qualquer tecnologia e qualquer caso de uso.
Voltando à ideia do Electron:
VS Code eu já citei e é bom.
Discord é reconhecidamente pesado, é até meme isso. Para um simples aplicativo de chat o tempo de inicialização é ridículo, pior do que o que falavam do Java inicializando um container web.
Atom eu já vi críticas sobre consumir memória demais para abrir um simples arquivo. O fato das máquinas atuais aguentarem não torna menos pesado.
GitHub Desktop não estou ligado.
Slack o pessoal precisa usar desktop? Uso a versão web e parece funcionar muito bem. Não sei qual é o peso da versão desktop então não vou opinar.
Tenho Teams e Skype instalados na minha máquina de trabalho mas quase não uso. A inicialização dos dois acaba com o tempo de boot da máquina, e não estou falando do startup do Windows e sim de depois que a sessão já abriu, tanto que quase sempre hiberno a sessão, só deixo para reiniciar em último caso. É um Core i5 de 5a ou 6a geração com 8 GB RAM e Windows 7, nada terrivelmente desatualizado (para a época que estou escrevendo isso). (perdão, depois vi que é de 2a geração).
Não estou desmerecendo todos os casos de uso do Electron. Dependendo das tecnologias que ele dá acesso pode ser vantagem usar. WhatsApp Desktop e Skype são aplicações de peso (no pun intended) e juntando as outras aplicações que você citou acho relevantes (por isso não falei do que não sabia e só citei o VS Code). Mas isso não quer dizer que desktop só deva ser feito com Electron. Como falei tem que ver outros fatores, analisar outras tecnologias (não só Java), casos de uso e disponibilidade de equipe.
Tem razão que Electron não é única, só citei um exemplo do está bem a frente do Java na atualidade como escolha para novas ferramentas desktop. Concordo que nem tudo deve ser feito com Electron. Para ferramentas mais robustas, a exemplo de algo tipo Photoshop, o ideal ainda é usar C/C++.
Nunca usei o Slack, mas na empresa que trabalho a maioria usa o Teams no desktop e mobile. Mais prático do que ficar com Teams perdido no meio das abas do browser. Agora pra home office ta sendo usado mais do que nunca.
Nunca tive interesse pelo Atom. Se ele tem problema com consumo de memória, é problema de quem programou, pois o VS Code é muito bom.
8 GB de RAM pra uma estação de trabalho hoje em dia é muito pouco. Só meu celular tem 6 GB, o notebook 16GB, que pra mim hoje é o mínimo para ter várias ferramentas abertas ao mesmo tempo. Sem SSD então é impraticável.
1 curtida
Concordo que embutir o browser deve dar acesso a muita coisa pronta, numa época de alta concorrência entre produtos e necessidade de soltar features novas rápido envolvendo Integrações isso é uma importante vantagem. Quer uma integração fácil com Google Docs ou Google Drive por exemplo, está na mão. Java realmente não oferece recursos nesse sentido e acho que nunca teve essa proposta. Ele conquistou espaço em aplicações desktop simples, desde linha-de-comando até GUIs pouco integradas com acesso à web, no backend, onde não há exigências de interface gráfica condizente com a experiência do sistema operacional ou de uma interface unificada um pouco mais pobre, e até certo ponto no mobile, onde deve ser enfraquecido ainda mais quando vier o Fuchsia OS, então frequentemente não vai atender novos requisitos principalmente para desktop com uso mais intensivo de recursos web, só acho importante estar ciente dos custos envolvidos em adotar o Electron. Para quem quer se manter no mainstream conhecer Electron parece ser bem importante, não tanto quanto web em si em termos de vagas, mas bastante relevante. Para quem já investiu no Java e tem interesse em algum de seus outros nichos como o de backend, o futuro à frente ainda é longo, a tecnologia é robusta (claro que novas tecnologias feitas do zero sempre vão tentar ser melhores) e muitas empresas investiram e ainda investem no Java como tecnologia. Mas como isso muda muito não garanto que dê pra se aposentar com ela, nem mesmo quem já está nela há muito tempo. Existe a pretensão por parte dos desenvolvedores da linguagem que dê, que seja tecnologia para mais 30 anos. Mas eles não têm controle da dinâmica e demandas do mercado.
O mundo da tecnologia é assim mesmo, não se deve ter apego a tecnologia X. Está sujeito a isso o uso de qualquer tecnologia adicional que nao seja C/C++ com uso das APIs na unha.
1 curtida
Mesmo para C/C++ as linguagens até gozam de estabilidade mas as técnicas empregadas mudam, sistemas operacionais evoluem, hardware evolui, sem falar das linguagens em si.
Dito tudo isso, não posso deixar de concordar com quase todos os pontos do @j-menezes, e agradecer pela dica da GraalVM. 
Agradecer também ao @javaflex pelos insights e discussão.
2 curtidas
Quis dizer C++ em si mesmo, sem depender da “ferramenta da moda”. Claro que os recursos acessados evoluem, como arquitetura de hardwares e SOs. Evoluções em tecnologias são inevitáveis, em jogos por exemplo as engines em C++ sempre precisam ser evoluídas, mas continuam usando C++.
C++ tem uso sim hoje em dia e sempre deverá ter (imagino Eu).
Mas Java passou C/C++ em popularidade não foi por acaso, principalmente por cobrir os problemas criticos de C e ate’ C++.
Volto a escrever, a linguagem C/C++ a exemplo de JavaScript não são boas pra dar manutenção, mesmo no C/C++ ANSI.
Alias somente quem já sofreu com elas pode falar.
Quero uma linguagem/plataforma que me possibilita rodar nos muitos sistemas operacionais, que seja boa de manutenção, que seja segura, op’s não tô vendo nada na frente do Java.
Sim. Eu pensei em programação de sistemas, coisas mais baixo nível.
Typescript é muito bom de dar manutenção também, a tipagem é bem presente nela
“A tipagem é bem presente nela” é até eufemismo. O objetivo todo do TypeScript até onde sei é cobrir essa deficiência de berço do JavaScript. Por isso anda tão popular entre os JSzeiros há alguns anos. Mas, sem conhecimento de causa, não tenho certeza se em uma linguagem dinâmica de origem isso consegue ser compensado tão bem. É mais ou menos como Java e recursos de programação funcional, ou Java e Generics, que foram encaixados depois. Mas estou especulando.
C e C++ não foram feitas pensando em portabilidade e como o @j-menezes falou para programação de aplicações o Java introduziu várias vantagens, na verdade esta já foi criada pensando em incorporar parte da comunidade pré-existente de desenvolvedores C/C++, você pode ver isso pela semelhança da sintaxe e pelas vantagens citadas. Hoje em dia portabilidade nas linguagens que saem é bem mais comum pelo que sei, acho até que a grande maioria é portável.
Em termos de produtividade eu admiro a que o pessoal do meu departamento tem com Ruby + Rails em desenvolvimento Web, que mesmo sendo uma linguagem dinâmica e sofrendo com erros de tipos em tempo de execução conseguem tirar da cartola funcionalidades mais rápido do que eu consigo no Java. Mas não acho que isso tenha a ver com a tipagem dinâmica e sim com os recursos prontos que essa combinação fornece. Agora, apesar das qualidades o hype dela passou, mas teve muito pioneirismo nessa frente que outros frameworks adotaram.
Melhor que o Java atualmente e dentro da mesma proposta tem o C#. Em termos de recursos da linguagem é objetivamente melhor servida que Java, depois que você compara os recursos tem que ser muito fanboy pra negar isso. Claro que para quem já está no Java e não tem tanta facilidade de migrar entre linguagens não compensa mudar, mas na dinâmica atual das linguagens para quem está começando eu olharia para o C# com muito mais carinho.
E tem PHP, que nem linguagem é, tou só trollando 
Ainda sobre manutenção, isso depende não só da linguagem mas também de quem está colocando a mão no projeto. De forma geral uma aplicação que foi construída à base de estagiários sem experiência por exemplo vai ter problemas de arquitetura e design mais sérios e potencialmente difíceis de resolver (pelas decisões tomadas no início do projeto, lembre-se: “arquitetura são as partes difíceis de mudar”), consequentemente mais custosos, que uma sendo feita por uma equipe mais sênior e experiente. E quanto menos versados na tecnologia e no tipo de aplicação que está sendo desenvolvido maior tende a ser esse custo. Por isso é importante se desenvolver não só em proficiência na linguagem, mas também em coisas como os tipos de projetos que você pretende atuar e em conhecimentos gerais de engenharia de software, arquitetura e design. É popular por exemplo se falar em SOLID e afins, mas eu vejo isso só como uma checklist de qualidade, não como um conhecimento estruturado em design de aplicações, que envolve por exemplo conhecimento em modelagem conceitual e de domínio, design orientado a objetos, entre outros que não são tão hypados e merecem ser estudados.
Também Java tem um defeito, ela é estritamente orientada a objetos, atualmente com recursos de programação funcional, mas não dá pra se dizer que seja genuinamente funcional. Existem outros paradigmas, e ficar só no Java vicia seu conhecimento em ficar só na orientação a objetos e no design orientado a objetos, em vez de permitir um aprendizado mais holístico.
estou migrando meus software em Java Desktop para Django Admin
1 curtida
Falei falei e chovi no molhado kkk.
Não é como o encaixe o bizarro da programação funcional no Java, que devido sua natureza burocrática e engessada na OOP, seria muito difícil encaixar isso na linguagem de forma limpa. No caso do TypeScript não, adiciona recursos ao JS sem se prender a “arquitetura” do JS. É um código independente para uso em tempo de desenvolvimento, depois é “compilado” para javascript puro.
Trabalho com .NET Core e C# sempre esteve anos luz na frente da linguagem Java em recursos e produtividade.
PHP tem seus méritos, é a tecnologia menos burocrática de todas para web, se encaixa bem para projetos de pequeno porte e baixo orçamento. Mas jamais escolheria pra grande porte, só agora na versão 8 está começando a usar compilação just in time.
Ruby o Rails foi a coisa mais importante que surgiu naquela época. Nunca usei, mas ele fez balançar todas as outras tecnologias para se tornarem mais simples.