Por que o Spring é melhor que o JEE?

Spring é menos pior que JEE.

A tendencia hoje em dia é projetos usando arquiteturas e linguagens mais modernas. Mas se seu objetivo é trabalhar com legado, sim, tem muito monolítico em Spring e JEE pra dar manutenção.

Se está sendo obrigado a usar Java, a linha Spring é mais leve e evoluída para aplicações web. De qualquer forma estará sob o peso básico da plataforma Java e os atrasos da linguagem.

Apesar da pequena evolução, Java EE foi concebido no tempo em que se acreditava na ideia furada que tudo seria feito em Java, aplicações client Java com servidor JEE trocando informações diretamente via Java.

Tem melhores alternativas hoje do que usar Java?

Go por exemplo. E .Net Core é uma opção mais leve para desenvolvedores C#.

Só para dar mais alternativas, eu acredito que java é uma ótima opçao ainda hoje em dia.

Há várias alternativas de mvc frameworks, web service frameworks, sem falar numa vasta biblioteca para tudo que vier a precisar (relatórios, processamento de imagens, emails, etc).

O hype em cima de Go está bombando e vejo sendo muito usada em middleware. Nao tenho certeza se para aplicaçoes web vai pegar e nem se terá uma biblioteca tao vasta quanto em java.

Naturalmente Go vai demorar a pegar no mercado e ter um leque maior de bibliotecas, mas é fato sua eficiência para back-end para quem busca o que já é oferecido.

Acho que Java deveria ser recriado como aconteceu com .NET, para quem for criar novas aplicações usando algo mais enxuto para os tempos atuais. Java 9 tem o lance da modularização, mas ainda é o velho Java.

Ninguém usa essas linguagens modernas pra criar um monolítico que precisa tratar requisições web, processar imagens e gerar relatórios, tudo na mesma aplicação. Isso significa que você pode usar Go para criar microservices, linguagem X pra gerar relatório, linguagem Y pra processar imagens, etc.

Talvez por isso nenhuma linguagem vai pegar no mercado, e quem esta esperando por isso pra não correr o risco de estudar algo que não “pegou” é que pode acabar correndo o risco de ficar pra trás por não “pegar” a nova realidade do mercado.

A recriação do Java se chama Scala, infelizmente o resultado é uma linguagem complexa com compilador lento, então só resta ao povo que gosta de linguagens estáticas, e rejeita complexidade, se acostumar com uma linguagem dinâmica (difícil) ou abandonar a JVM para algo como Go (mais fácil em alguns casos, ex: microserviços).

Em relação a Scala, pela linguagem sim, foi uma tentativa já que a linguagem Java é bem atrasada. Mas Scala de qualquer forma depende da velha JDK, onde quis dizer que deveriam escrever outra do zero, como o .NET Core, que manteve C#, mas no caso da plataforma Java nem a linguagem se salva.

Atentando ao tema do tópico:
Você já instalou e configurou um application server como o Weblogic ou Websphere? Foi fácil? Teve dificuldades?
A questão com o JEE, além da defasagem causada pela lentidão na aceitação de inovações por parte do consórcio que comanda o Java, é o fato de ter a dependência de um AS.
O spring, por outro lado (outros lados) não está preso ao que um comitê define e, por isso, está há anos luz distante em termos de evolução e de facilidades.
Desta forma, o Spring é, em vários momentos, utilizado como base para tornar uma JSR uma realidade.
Porém, ano após ano, o java vem decepcionando com a não inclusão de N coisas bacanas (basta ver o tempo que levou para adotar a JodaTime como API padrão para datas e a resistência em implementar as expressões lambda, algo que o .Net já possuía há anos).

Você tocou numa questão que eu acho que deveria ser fundamental. A criação de linguagens X, Y ou Z para a mesma estrutura da JDK é o mesmo que pegar o motor de um fusca e construir uma Ferrari em volta. É bonitinha, tem bom acabamento, boa aerodinâmica, mas o motor não ajuda.
É o que acontece com o Groovy, também.

Exato. Groovy, Scala, Kotlin ajudam na produção, mas são só linguagens, o motor continua velho.

Oracle podia patrocinar uma galera pra escrever uma nova plataforma Java enxuta, como aconteceu com .NET Core.

Esse é outro ponto que eu não consegui distinguir. O java passou a “desevoluir” depois da aquisição pela Oracle? O tal JDK pago existe ou é lenda?
De qualquer maneira, seria sim, fundamental para o futuro do java que o mesmo fosse completamente reescrito. Nem que dessem outro nome, como kawa (que significa café, em polonês).

Pela lentidão, a Oracle deixou o Java praticamente parado no tempo. O que era muito bom naquela época não é mais tão bom para o horizonte atual.

Enquanto não vem um “kawa”, o que temos de melhor hoje para back-end na minha opinião são Go e .NET Core.

O duro é convencer empresas que já têm java rodando a abandonar isso. E essa é a minha realidade (mais ou menos por que eu sofro com SOA/OSB e etc)

Muito difícil abandonar. Assim como minha realidade é o .NET normal. Mas para quem for desenvolver novos projetos, tem ai novos caminhos.

@javaflex particularmente, eu vi algumas mudanças na JVM de uns anos para cá, no Java 8 tivemos a remoção do PermGen e agora no Java 9 temos a implementação de módulos … Em quais aspectos você afirma que a JVM está atrasada ? Que outras plataformas estariam à frente ? (estou perguntando de curiosidade mesmo, não para defender Java com unhas e dentes).

Pelo contrário. O Java ficou um bom tempo parado (5 anos) na versão 6 na mão da Sun. Depois da aquisição da Oracle o Hotspot (JDK oficial) incorporou parte do JRocket (JDK da Oracle, acho que ainda existe). Logo depois veio a versão 7, e desde então, veio uma nova versão a cada 3 anos. E esse ano já sai o Java 10.

JVM? Seria mais eficiente não ter VM, com aplicação e servidor livres desse custo em tempo de execução.

Já que não dá pra ser radical com Java e .Net em relação a JVM/CLR, pelo menos a Oracle também criar uma plataforma mais enxuta com uma stack própria decente.

Concordo que a Oracle começou a acordar, bem atrasada, a partir do Java 8.

Eu entrei nesse assunto pois a Oracle barrou as novas versões do MySQL (é óbvio que é plenamente compreensível neste caso, mas…). Inclusive, a versão 6 já estava pronta, até uma versão já estava rolando e isso foi cortado.

Quando, lá em 2010, comecei a desenvolver java, para o finado HSBC, ouvi muita gente dizer que o banco utilizava o JDK 1.4 por questões de estabilidade.
Hoje, 8 anos depois, fazendo manutenção em algumas apis da telefônica, vejo que isso não era de todo mentira, nem de todo verdade. Afinal, não é apenas em bancos que temos versões “defasadas”.

Interessante não é? Voltamos aos meios tradicionais, programar -> compilar -> rodar, a JVM chegou com a promessa do “Write once, run everywhere” e o que mais vemos são servidores paradinhos rodando aplicações sem tanta necessidade de migração vindas de outras plataformas, programa-se para android e no final é compilado para uma única plataforma (novamente migração desnecessária), a troca de banco de dados muitas das vezes nem precisa (jpa/hibernate fica triste ), chegou também com a questão do “Just in time” mas… compiladores também se atualizam/modernizam, ou seja, elas por elas a meu ver… acho que por essas características que java não substitui com competência para nichos bem específicos como firmwares (linguagem C, assembly, etc…) e games (C++ e até C#) por exemplo e estou acreditando que para web vai fraquejar também, questão de produtividade até php ganha nessa…

Sim, na verdade sempre foram mais eficientes linguagens portáveis em que podemos compilar diretamente para cada SO, sem precisar de uma engenhoca em tempo de execução.

Quanto menos overhead melhor, ainda mais em tempos que se paga por cada pelo recurso utilizado. Sem falar em escalabilidade, imagina n JVMs, n SessionFactory do Hibernate na vida toda da memória de cada aplicação, cache sem necessidade, recursos para abstrair SQL, etc. Considerando que a maioria usa JPA/Hibernate acessando 1 banco relacional. Claro que, sem deixar de usar uma boa linguagem de alto nível, para manter a aplicação com recursos necessários de forma produtiva.

Exato. Nesses nichos Java nem pensar.

Plataforma Java Sun/Oracle foi promessa pra tudo…

Desktop não vingou, por dificultar ter a qualidade nativa da UI de cada SO. Embora tenha tido o bom SWT oferecendo UI nativa, mas que infelizmente foi desprezado pela comunidade, mesmo na época que desktop ainda bombava. Mas usar Eclipse feito em SWT todo mundo queria.

Java Mobile da Sun/Oracle só deu certo no Symbian.

Applet morreu junto com todos os plugins malignos.

Sobrou back-end web (Nao sei afirmar se vai fraquejar, por causa do legado de profissionais, e Spring dá uma sobrevida para a produtividade, uma fuga da esquisitice da stack oficial Sun/Oracle).

Gostei da discussão e acrescento que, na minha opinião, talvez a única coisa que diferencie mesmo de fato o Spring do JEE é a questão da popularidade, graças a sucessão de problemas que os EJBs causaram (ou ainda causam) para quem tem projetos puramente JEE.

Mas, concordo com todos que é mais do mesmo. Eu sou um especialista em Java, conheço e sou a apaixonado desde a faculdade e até hj ainda invisto muito nesse conhecimento, mesmo pq, paga muito bem minhas contas e ainda sobra pra ir no Outback…rsrs

Mas como sou uma pessoa que não fica parada no tempo, tenho visto muitas evoluções tb em outras linguagens/plataformas que o Java já deveria ter tb.

No mais, acredito que temos que evoluir conforme as coisas evoluem. O difícil mesmo é fazer os clientes comprarem a idéia de tais coisas evoluindo…

Justamente o que eu havia dito, como o Spring é “livre” e não está sob a sombra do comitê do Java, ele pode evoluir rapidamente, como as distros linux. Surgiu um problema? A comunidade resolve e boa O que, para o JEE, é impossível (ao menos nessa dinâmica).

Tem como citar exemplos? Eu trabalho com SOA e boa parte do que se consome são WS SOAP (JAX-WS) de EJBs 2.5 e 3.1 e não identifico problemas (entendo que as aplicações são estáveis há alguns anos, mas, ainda há quem as crie).

Pode citar exemplos?

Com relação a isso, eu tenho visto em toda a minha carreira gente desenvolvendo em Windows e os seus artefatos sendo implementados em linux/unix. Mas, não é o artefato compilado, bonitinho. Geram-se os pacotes e os mesmos são compilados direto no SO em que a aplicação irá rodar e, aí sim, o produto final é colocado no ambiente.
Ou seja, eu nunca vi essa questão do write once, run everywhere na prática.

Acho que esse exemplo não é dos melhores, o android tem uma especificação própria, como o JME possuía, não? Tem elementos específicos, que inviabilizam colocar o código em um outro ambiente.
Aliás, se formos levar a ferro e fogo, temos hoje react e outras coisas (xamarin) que segue a mesma linha de raciocínio (embora seja preciso compilar para cada plataforma de maneira isolada).

Difícil mesmo. Pra tentar vender tem que mostrar em fatos que a solução vai custar menos, como aconteceu neste caso no mercado livre https://imasters.com.br/linguagens/o-ceu-e-o-limite-na-utilizacao-de-golang/

Como você falou, o que importa é pagar bem. Minha realidade é .Net, nem sonho em trabalhar com Go dentro da empresa, de perspectiva concreta só .Net Core.

E quando o problema não é o cliente em si, mas o arquiteto, o gerente da área, etc?

Só os especialistas.

Pode crer, geralmente o cliente nem está azul para o que está “por baixo dos panos”…

Cara, quando eu comecei a “frequentar” o guj com a outra conta (que foi injustamente bloqueada), lá em 2010 é que tinha especialista… Hoje tem muito cara bom, mas aquela época, meu, eu não entendia nada do que os caras escreviam aqui. E hoje entendo metade.

Faz tempo que eu aprendi que o cliente quer algo que funcione e resolva o problema dele. A maioria nem liga para quanto vai ser o valor no cheque.
O maior problema é depois que ele já pagou e o sistema já está rodando. Aí ele não quer mudar de jeito nenhum. Pois mudanças causam dor de cabeça e trazem problemas (entre os quais, prejuízos).

A infra também amarra, aqui o mundo se limita a .Net ou Java. Por isso seria positivo Java rejuvenescer, o que possibilita o uso dentro da mesma cultura, assim como .Net Core.

Eu não sei se eu serei um arquiteto muito chato (com relação à tecnologia). Mas, eu imagino que seria interessante dispor de opções para cada monstro que apareça.
Eu estive num processo seletivo, tempos atrás, numa startup, onde, na entrevista com os arquitetos, os caras perguntaram se eu tinha alguma “linguagem de estimação”. A filosofia deles era baseada em, quando uma nova solução deveria ser implementada (novo desenvolvimento), reunir arquitetos e a equipe responsável e aí definir em que linguagem seria desenvolvida. Tanto back como front.
Sei que esse cenário “dos sonhos” é distante, muito distante do que temos na maior parte das empresas. mas entendo que seja uma luz no fim do túmulo (sim, é túmulo mesmo).

Falando de EJBs, sim, realmente é osso trabalhar com eles.

A promessa de que eles iriam facilitar a implementação em aplicações de missão crítica,
com escalabilidade, ser fácil de se implementar e aumentar a produtividade do desenvolvedor é tudo mentira.

Por exemplo, um cara Sênior iria se preocupar em, ao implementar uma EJBObject:

1. Business Interface (BI): definir APENAS os metodos de negócio necessários
2. Remote Interface: extende a BI E EJBObject (de novo!)
3. Bean: implementa a BI

Isso pq? Ele sabe que, fazer uma implementação de EJBObject vai implicar em ter que implementar TODOS os metodos dessa interface.

Mas e um novato/Jr/Pleno? Ele sabe o que é um sistema distribuído? Entende bem a especificação e seus usos corretos?

Além disso, pensar emn construir um projeto envolvendo EJB quer dizer que vc quer um sistema “Peso Pesado” que torna muito difícil entrar numa
discussão sobre granularidade dos Beans em si.

Eu tenho visto projetos por aí em que os caras vão lá e se entitulam “arquitetos do POO” e botam um sistema de EJBs utilizando construtores para implementaro ejbCreate com assinaturas diferentes.
Meu Deus! (quis dizer: morri). Vc não sabe a dor de cabeça que isso acarreta…

Por ser um “Peso Pesado”, tb custa caro pra o cliente. Pra vc implementar essa especificação, vai ter que pagar uma licença de WebLogic, Websphere, etc… Vamos ser sinceros, nem todo cliente tem budget pra arcar com isso
e, geralmente, nem quer…

Esse post aqui fala bem sobre alguns problemas que uma arquitetura assim pode trazer: https://dzone.com/articles/top-10-causes-java-ee

Falando sobre linguagens:

Erlang: linguagem para construir sistemas massivamente escaláveis com requerimentos de alta disponibilidade (<a href="https://www.erlang.org/">https://www.erlang.org/</a>);

Go: linguagem para construção de software simples e eficiente (<a href="https://golang.org/">https://golang.org/</a>);

Groovy: linguagem dinamica, poderosa com compilação estática que aumenta a produtividade de forma concisa(<a href="http://groovy-lang.org/">http://groovy-lang.org/</a>);

Haskell: linguagem considerada puramente funcional (<a href="https://www.haskell.org/">https://www.haskell.org/</a>);

OCaml: linguagem com suporte funcional, imperativo que é baseada no estilo POO (<a href="https://ocaml.org/">https://ocaml.org/</a>);

Tem mais coisas por aí pra falar de tudo que eu falei, pois, a evolução está sempre a nossa porta e o tempo não pára…

Groovy entra na mesma questão do Scala, não? É uma p**a duma linguagem, massss, roda sobre a JVM.

Aqui eu vejo dois pontos discutíveis: realmente, EJB não é para o tiozinho da padaria que só tem aquela unidade e não planeja criar um império de padarias.
Esse cara sim, deve ter um sistema muito mais flexível, leve e simples, tanto para construir, quanto para manter.
E, aí sim eu concordo que não tem espaço para nada da especificação EJB, aliás, nem java.
Agora, eu trabalhei e trabalho com EJBs desde 2010, em empresas de setores bancários, logístico, rastreamento e telecomunicações. Acha que não tem cacife para bancar isso?
Tem e de sobra. Tanto que eu, atualmente, tenho o privilégio (ou seria a pena a cumprir?) de trabalhar com SOA (bpel, mediators), OSB (o ESB da Oracle), pois há licenças full para a Oracle SOA Suíte.
E, como o SOA/OSB são meramente meios, temos aplicações rodando com EJB que são gigantes (e foi para serem assim que foram criadas) e rodam tranquilamente.
É óbvio que tudo o que temos aqui poderia ser, facilmente, substituído por sistemas em PHP, Python, GO, RoR, etc.
Então, temos várias realidades distintas e, para a realidade que eu vivi e vivo, o EJB não só atende como é uma ótima opção.
Lógico que eu preferiria aplicações com Spring e tudo mais, mas não depende apenas de mim

Pois é, esse é o espírito. Temos mesmo que viver aquilo que sabemos e dominamos. Mas, as portas da mente sempre devem estar abertas para novos aprendizados e experiências.

Eu conheço muito bem tb toda essa parafernalha aí de SOA e EJB. Hoje trabalho só com SOA e com a integração do eSocial do Governo Federal, onde tenho mensagens SOAP, comunicação TLS e outros features e, sinceramente, tb estou bem feliz com o que me pagam por isso…rsrs

Então, por isso eu estou sempre me atualizando. Atualmente, estou estudando Qlikview e algumas coisas de ETL. Posteriormente, quero pegar firme em nodejs, react/redux e algumas coisas mais.

E por um acaso existe linguagem dinâmica que não roda sobre VM ou que não seja interpretada ?

Java é o assembly da jvm, não faz sentido criar apps web com assembly. Você deve usar uma das dezenas alternativas que existem na jvm para criar aplicações web com muito menos codigo.

Pra galera querendo que a JVM evolua, vale lembrar que agora teremos atualizações a cada seis meses, e a versão 9 já possui AOT para casos específicos.
http://openjdk.java.net/jeps/295
Fora as demais features que pessoal sempre quis e ao menos agora estão chegando,local type inference, Pattern matching, value types, co routines, java on java e etc.

Pra quem reclama de linguagens que rodam sobre a jvm, Kotlin e Scala possuem a opção de rodar nativo (Kotlin tá mais evoluído nessa parte).
https://kotlinlang.org/docs/reference/native-overview.html

Pra quem acha que JVM é um motor de fusca http://making.duolingo.com/rewriting-duolingos-engine-in-scala

Vocês esquecem que a evolução do Java é mais lenta devido ao compromisso de manterem a compatibilidade com versões antigas …
Claro q seria mais fácil fazer como várias outras linguagens que lançam uma nova versão e o usuário que se foda… mas esse foi um compromisso assumido lá trás e que agora está mudando aos poucos. Tanto que finalmente começaram a remover código depreciado (corba ,applets e afins)…

agora um adendo, eu frequento esse fórum há vários anos e qdo usava-se o antigo jforum raramente o sistema saía do ar, e olha que a estrutura era bem antiga, e a quantidade de gente acessando era bem maior.
Hoje em dia com essa estrutura nova, que usa o RoR e Ember só dá pau -.-’

Enfim, paciência jovens …

Então você defende não ter VM em si, é isso ? Porque o que eu queria entender era a deficiência da JVM em relação a outras máquinas virtuais ou plataforma interpretadas, e pelo o que eu vejo, o único concorrente à altura é o .NET mesmo.

Com relação ao Golan, eu precisaria me aprofundar, mas pelo que me parece, o ganho de desempenho está mais relacionado ao uso de I/O assíncrono e o modelo de concorrência do que pelo fato de usar código nativo. Pelo menos no contexto da Web e dos microserviços, é uma explicação que faz mais sentido.

E uma coisa a se prestar atençao é que a maioria das pessoas impressionadas com a performance de Go, sao pessoas migrando de linguagens dinâmicas: ruby, python ou groovy (como no link acima). Essas linguagens nao tem foco em performance entao é normal obter ganhos absurdos.
Go pode performar melhor do que Java em alguns cenários, ou vice-versa, mas nao é que uma esteja há ordens de magnitude da outra.

Mas é neste contexto mesmo.

Novos projetos não precisam de compatibilidade. Não é mais aquela visão furada antiga que tudo seria integrado via EJBs.

A questão levantada foi de ter uma nova plataforma mais enxuta, com stack própria decente como .Net Core, pelo menos para web, onde é a maior demanda. Para novas aplicações, sem se preocupar com compatibilidade, o legado continuaria para a velha JDK/JRE, que teria continuidade.

Vcs estão misturando as coisas.
Java SE é uma coisa … Java EE é outra …

Java EE o próprio nome já diz “Enterprise” … Não foi feito para sistemas pequenos… A ideia era outra msm…

E bom para a parte web vc tem outras abordagens mais leves e eficientes rapidoid, vert.x e afins

Mesmo que seja, filas e ESBs estão aí para isso, não estão?
Retrocompatibilidade, nos dias de hoje, é retrocesso.
Toda a maravilha do .Net é essa.
Aliás, se pegarmos coisas “mais gourmetizadas” como o Angular, não existe compatibilidade entre a versão js (1) e as demais…

Era o que eu vinha dizendo desde o começo.
Como eu comentei, é possível sim construir um ERP, um CRM completo com php, node ou python? Sim.
Agora, o ideal para tais linguagens é outro foco de mercado…

Java EE fez parte de uma ideia antiga. O conceito de projeto “grande” hoje não é o mesmo da época desses grandes legados. Hoje são vários sistemas modulares, menores, focados em cada setor ou finalidade, onde a integração entre sistemas não depende de uma única tecnologia parruda. Em maioria hoje são web mesmo rodando na intranet.

Retrocompatibilidade não é retrocesso… tudo depende do negócio. Se vc é uma fábrica de software q faz algo “descartável” para durar só alguns anos e jogar fora, tudo bem a tecnologia mudar e etc…

Agora qdo vc precisa q o mesmo sistema rode durante décadas … As coisas mudam.

Maioria dos novos sistemas se integram via REST. Em relação a legados nem entro nessa questão, maioria podem continuar usando o que usam mesmo.

Nao uso frameworks SPA pois nao trabalho com SPA, mas acompanho esses frameworks Js que aparecem e desaparecem a cada hora. Em relação a quebra de compatibilidade do Angular, só acho que ficou feio por ter acontecido já na primeira versão, foi muito mal projetado. Por outro lado foi uma forma dele sobreviver diante de outros que surgiram.

Já o Java quantos anos tem? Nao ficaria mal criarem uma nova plataforma conforme já explicado para novos projetos. Pelo menos como no .NET, não seria para matar a plataforma atual, mas de ter uma nova opção mantida por outra equipe.

Fábrica de software é um caso bem ruim mesmo, onde o importante é só vender. Mas no geral o mundo está sempre em transformação, surgem novos horizontes para o negócio da empresa, e assim novas oportunidades aparecem para o setor de TI. Web e depois mobile por exemplo foram boom para novos desenvolvimentos dentro de várias Negócios.

Que, teoricamente, seria o intuito de qualquer sistema “de peso”.
Já a questão das fábricas de software, o problema maior é a visão, comum à maioria dos gestores (empresas não decidem nada, quem decide é o gestor, como e por quê, são outros quinhentos), que entendem que terceirizar a TI e o SI é a solução para tudo.
Aí é o que acontece com o que eu faço hoje, além de manter/criar coisas em OSB/SOA, dou manutenção num BPM antiquado, complexo (ok, o negócio e o BPM são complexos sim) e de difícil manutenção.