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.
1 curtida
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”.
1 curtida
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…
2 curtidas
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).
2 curtidas
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…
2 curtidas
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?
2 curtidas
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).
3 curtidas
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.
2 curtidas
E quando o problema não é o cliente em si, mas o arquiteto, o gerente da área, etc?
2 curtidas
Só os especialistas.
1 curtida
Pode crer, geralmente o cliente nem está azul para o que está “por baixo dos panos”…
1 curtida
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.
1 curtida
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).
2 curtidas
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.
1 curtida
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).
1 curtida
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:
- Business Interface (BI): definir APENAS os metodos de negócio necessários
- Remote Interface: extende a BI E EJBObject (de novo!)
- 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 (https://www.erlang.org/);
Go: linguagem para construção de software simples e eficiente (https://golang.org/);
Groovy: linguagem dinamica, poderosa com compilação estática que aumenta a produtividade de forma concisa(http://groovy-lang.org/);
Haskell: linguagem considerada puramente funcional (https://www.haskell.org/);
OCaml: linguagem com suporte funcional, imperativo que é baseada no estilo POO (https://ocaml.org/);
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.
1 curtida