Cada dia que passa eu fico mais convencido que Java precisa rumar para a aposentadoria. Diferente das pessoas que apostam no futuro da plataforma, também acredito que ela já mostra sinais de idade. Java é uma linguagem que já cumpriu seu papel, educou a grande massa sobre bom desenvolvimento OO e aumentou a exigência que temos sobre o ambiênte de execução. Só que hoje estamos voltando a enfrentar grandes limitações por conta da linguagem.
Vou primeiro falar da linguagem. Ela foi concebida para ser apenas um C++ melhor, mais simples e usavel; e C++ é uma gambiarra desde seu início. Hoje os softwares são maiores e exigem melhores abstrações, que Java simplesmente não tem como oferecer. Está na hora de termos uma linguagem com suporte a recursos avançados, e já existe uma massa grande o suficiente de desenvolvedores capacitados para usá-las. Acredito que já podemos introduzir no mainstream suporte a closures, type classes e macros.
Type classes permitem uma maior expressividade na hora de estabelecer contratos e os evoluir, isso é fundamental para tornar a linguagem escalavel, melhorar suas chances no ‘programming in the large’. Essa é, inclusive, a opinião de alguns pesquisadores, que criaram um protótipo de linguagem que funde Java 5 com type classes do Haskell. O resultado é um pouco confuso, mas é um ótimo exemplo de como avançar as capacidades da linguagem.
Macros permitem modelar a linguagem da forma que melhor te servir. Seja criando atalhos para idiomas comuns, ou criando DSLs. São duas as técnicas usuais para se implementar macros: a primeira é como scheme implementa, via syntax case e quotations, que podem ser entendidos por um regexp e replace feitos em cima da estrutura da linguagem; a outra é via parser transformers, como Erlang implementa e, de certa forma, o Eclipse usa para fazer refactoring, nele você edita via um programa normal o AST de cada unidade de compilação durante as várias etapas do processo. Parser transformations permitem experimentar com sintaxe da linguagem facilmente. Porém hygienic macros ala scheme são mais faceis de usar e podemos ver isso no Java Syntactic Extender que era uma pesquisa de como implementá-las no Java.
Quanto a closures, acredito que não preciso argumentar a respeito, pois qualquer pessoa que brincou com Ruby, por exemplo, sabe do poder e versatilidade delas. Vários idiomas funcionais são impraticáveis de usar em linguagens orientadas a objeto sem closures. O Neal Gafter discute isso a fundo em seu blog.
Java tornou obrigatório um runtime que tivesse gerenciamento automático de memória e tipagem forte garantida em runtime. Hoje vejo que temos novos problemas que deveriam ser resolvidos pelo ambiente de execução, entre eles resiliência, melhor gerênciamento de recursos e maior suporte para programação paralela.
Um programa Java que gera um OutOfMemoryError tem que ser reiniciado porque não tem como continuar e se recuperar de forma controlada - me digam o nome de um AS que lide bem com OOM. Em um sistema OLTP não temos como gerênciar o consumo individual de recursos de cada transação e isso é um elemento fundamental para garantir um bom SLA. Imaginem se pudessemos limitar o tempo de processamos e memória utilizada por cada requisição feita a um servlet container.
Por fim, temos programação paralela, que é um belo inferno em Java: lidar com sincronização, deadlocks, livelocks, race conditions e o trabalho todo que é paralelisar o programa. Temos que gastar um enorme tempo fazendo tunning do tamanho dos thread-pools, das filas de eventos/mensagens e escolher bem as estruturas de dados. Agora se tivessemos, por exemplo, corrotinas com fork/join suportadas nativamente, ou ainda o modelo leve de processos de Erlang, programação paralela seria mais intuitiva, simples e seria mais facil extrair maior performance.
Resumindo, acho que estamos no ponto que passa a ser realmente importante avançarmos a tecnologia utilizada. Java ainda resolve muito bem, mas eu vejo no meu dia-a-dia vários projetos que apanham por não ter mais expressividade na linguagem ou um runtime mais robusto, mais preparado para os novos desafios de hoje.
14 responses so far ↓
1 Christiano Milfont // Dec 29, 2006 at 8:35 am
Rodrigo, mas a partir da abertura que o java 6 vem trazendo para outras linguagens na JVM alem de java como o javscript por exemplo, a plataforma não está evoluindo nisso que voce propõe?
acredito que esse suporte a outras linguagens trará essa flexibilidade desejada.
2 Rafael Chaves // Dec 29, 2006 at 12:16 pm
Não penso que o runtime Java deva ser substituído por algo melhor, e sim evoluído conforme necessário, e com bastante cuidado. Java (o runtime) atingiu um status inigualável com boa parte da indústria de software (fornecedores ou consumidores da tecnologia), equiparando-se ou superando em importância mesmo as APIs do Windows promovidas pela Microsoft, exatamente por ser um mercado multi-fornecedor, tudo que a MS não quer. Jogar essa posição fora seria (economicamente falando) uma grande burrice, e uma excelente oportunidade para a MS conquistar mais espaço com a sua estratégia “all things Windows”, o que para mim seria extremamente danoso para a indústria.
A linguagem é apenas a interface com usuário (programadores) do runtime/API, e sendo assim, é pouco relevante, requer menos conservadorismo, e pode ser evoluída/substituída se necessário.
Não estou dizendo que a academia deveria se satisfazer com o runtime de Java, e se limitar a melhorá-lo/estendê-lo. A academia não tem compromissos com base instalada, ou preocupações em proteger o mercado de monopólios, sendo livre para criar sem limites.
3 Luiz // Dec 29, 2006 at 1:21 pm
Java não é apenas linguagem, mas tbm uma plataforma completa, sendo assim, devemos considerar que não é viável do ponto de vista financeiro, reconstruir uma plataforma inteira do zero apenas p/ mudar sua linguagem. Podemos ver isso na plataforma .NET, que esta anos luz atrás do java, mesmo a M$ aproveitando muita coisa ainda falta muito p/ atingir uma maturidade igualável ao do Java.
Na minha opinião a plataforma vai continuar a evoluir inclusive a sua linguagem e com certeza em breve poderemos escolher a linguagem que quisermos para programar na plataforma Java.
Acredito que a JVM tbm continuará a evoluir e com certeza problemas que existem hoje desaparecerão em um futuro próximo, uma grande oportunidade de se criar coisas novas.
E por final não devemos esquecer que existem muitas linguagens e cada uma foi feito para um objetivo específico e penso ser impossível uma linguagem resolver todos os problemas isso ainda é uma utopia, mas java esta fazendo um grande trabalho.
4 kumpera // Jan 3, 2007 at 10:45 pm
Cristiano, algumas das coisas que eu gostaria de ver na linguagem são alterações muito profundas na plataforma que significariam quebra de compatibilidade com a base instalada; suporte a processos leves é um exemplo de mudança que não tem como simplesmente ser adicionada.
Luiz/Rafael, jogar fora toda tecnologia que existe por traz da HotSpot definitivamente é loucura, porém um caminho que vejo como viavel é a criação de tecnologias que, além da sua inovação, executem código java. Algo semelhante à IKVM, de forma a ser um superconjunto da linguagem.
5 Paulo Silveira // Jan 7, 2007 at 9:47 pm
O próprio Bracha, ex-sun, falava que adoraria poder mudar toda a linguagem e quebrar a compatibilidade! Tinha até o nome para uma linguagem nova (Kenya?). Pena que ele saiu….
Kumpera, quando java se aposentar, ainda vai sobrar MUITO, mas MUITO legado para dar consultoria!
6 Christiano Milfont // Jan 8, 2007 at 11:51 am
Rodrigo, acredito que em um momento (quem sabe a partir o J7) se quebre a compatibilidade…
o problema nisso vai ser mais politico que operacional, com a imposição dos BigPlayers para não se fazer isso…
mas pensando bem quem tem um ambiente proprietario hoje praticamente nao tem compatibilidade entre versões, eu que o diga com o Oracle aqui…
7 kumpera // Jan 8, 2007 at 10:44 pm
Paulo, o Bracha vai fazer muita coisa interessante agora que não precisa mais se preocupar com Java, ele deve estar um pouco estafado com o trampo todo que generics foi.
.
Quanto a ter consultoria de sobra, bom, primeiro acho que Java não vai realmente se aposentar, vai ser absorvido dentro de outra plataforma - apesar que os sistemas legados vão ser sempre um belo filão.
.
Christiano, não acho prudente ou mesmo razoável quebrar a compatibilidade dos releases do Java. Espero mesmo que isso não aconteça, o que gostaria de ver são novos esforços para avançar o state-of-art em desenvolvimento.
8 luciano elias regino // May 13, 2007 at 12:22 am
estudei sobre a linguagem kenya na unesa e aprendi que ela era considerada como um java melhorado mas mudei de periodo e não tive mais contato com a mesma.mas mesmo assim me interesso por me atualizar sobre essa linguagem gostaria de obter mais informações sobre a linguagem até como instalar o compilador em ambiente windows pois já o desinstalei e quero reinstala-lo mas não me lembro como.obtive o compilador kenya no site
http://chatley.com/kenya
se possivel alguem do blog puder me indicar o maximo possivel de numero de links onde obter informações sobre a mesma ficaria muito grato.
obrigado.
luciano elias regino.
lucianoregino@msm.com.br
9 Lucas // Dec 6, 2007 at 12:17 am
Bom meu grande … entao me diz algo melhor mais bem documentado ficarei feliz em poder aprender … mais nao uma q resolva apenas esses problemas mas sim de uma solução para esses problemas e ainda supram todas as outras vantagens do java ainda estou querendo conhecer
10 logan // Dec 9, 2007 at 6:39 pm
Meu caro, Cobol ainda é a linguagem que mais tem linhas de código e que processa algo como 50% das transações web no mundo. Acho que a plataforma tem que evoluir e vai evoluir cada vez mais. Não será um recurso ou outro que não está disponível, que vai derrubar uma plataforma sólida como Java. E não são só os grandes players, a comunidade também apóia o Java , no freshmeat ela só perde para o C em quantidade de projetos. Agora o Google lançou o Android… Preciso dizer mais…
11 Tulio Rodrigues // Mar 11, 2008 at 10:36 am
Acredito que a Sun não permitirá que a linguagem Java fique para traz, provavelmente nos proximos anos veremos novos realeses do SDK com features realmente interessantes. Antes quando ouvia falar sobre Ruby e como ele era bom entre outras coisas, achava que era tudo uma grande besteira e modismo, mas ao começar estuda-la vi o quanto a linguagem java precisa evoluir, o nivel de abstração de OO em Ruby é bem alto e possui caracteristicas realmente importantes e beneficas.
Acho que como aconteceu quando surgiu a plataforma .Net o Java vai evoluir de certa forma para que atenda a nova realidade.
12 Bruno // Apr 19, 2008 at 10:27 am
Quase todos os POSTs tem argumentos válidos, mas acho que o ponto do Kumpera é a evolução das linguagens e das técnicas.
Assim, neste contexto, acredito que 2 coisas podem afetar de alguma maneira a evolução das linguagens e das técnicas:
1) A vontade das empresas(fornecedoras e consumidoras) de proteger o investimento nos produtos/aplicativos existentes incluíndo ter profissionais (motivados a trabalhar com a “última” tecnologia) disponíveis no mercado — veja a dificuldade em contratar profissionais COBOL hoje, para eles é um grande problema. Imagine se o foco(em JAVA) começar a mudar, ainda que lentamente para outra plataforma, de alguma maneira “mais interessante” aos desenvolvedores.
2) A vontade de algumas pessoas de manter seus conhecimentos atuais classificados como “atuais” por mais alguns anos reforça o primeiro argumento…
Bom, além disto a CRL (.NET/Mono) me parece mais preparada para lidar com os novos desafios que a JVM atual.
Eu desenvolvo principalmente em .NET, não me orgulho em criticar a JVM, gostaria que ela fosse melhorada sim… há muita coisa boa no http://www.apache.org para JAVA hoje, algo que está só começando para .NET, e muita coisa é portada do “Mundo JAVA” — ecosistema open source: sim existe para .NET também!
[]s
13 Débito Técnico » Blog Archive » Behavior-Driven Development e o Jogo da Memória // Jun 12, 2008 at 12:24 am
[...] tenho estudado bastante Ruby. Concordo com o Rodrigo Kumpera quando ele diz que Java “educou a grande massa sobre bom desenvolvimento OO” mas “cheira [...]
14 Aquila // Aug 14, 2008 at 5:26 pm
Amigo, coisa simples para você pensar.
Sim verdade que o java tem muitas limitações, tenho que reconhecer já que sou um desenvolvedor java,C#,Python,(atualmente estudando Ruby ‘n Rails). Se acredita mesmo que vai achar uma linguagem que faça tudo esta engado pelo menos por enquanto, outra coisa importante a se resaltar é as atualizações de uma linguagem devem ser acompanhadas para ver suas melhorias e não continuar na primeira versão com medo de novas atualizações não serem estaveis, como muitos desenvolvedores que utilizão a Jdk 1.4 até hoje e diz o java não tem nada.
TI é atualizão constante de informações, é estreitamente necessario aprender e desenvolver novas aprimorações.
se não sentir satisfação faça como um amigo meu , crie os componentes que precisa.
Abs , boa sorte!
Leave a Comment