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.
1 curtida
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
1 curtida
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…
1 curtida
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.