Faz mais de ano falei sobre o que o java 8 ia trazer. Finalmente ele chegou. E agora? Valeu a pena esperar?
Em uma palavra: sim. Em mais palavras: nem tanto.
O java finalmente tinha a chance de ultrapassar a concorrência, especialmente o c#, e embora tenha ido onde o c# não foi possibilitando o uso de lambas em vez SAM types, deixou para tràs o óbvio: monads e expression trees. Uma das features que todos querem copiar é o LINQ. O LINQ tem vários sabores. Temos o LINQ to Collections e o LINQ to SQL (existem outros como o LINQ to XML, mas os dois primeiros são os mais usados).
O LINQ to Collections faz o mesmo que a nova api de Stream do Java 8. Até aqui tudo bem. A existência de lambdas pede pela existência de melhor manipulação de coleções (Iterable para ser mais exato). O que o LINQ to SQL faz é usar a mesma sintaxe e semântica que o LINQ to Collections para acessar bancos de dados, especialmente usando o Entity Framework (embora existam outras formas). O ponto é que o programador não precisa saber duas apis, um para coleções na memoria e uma para coleções no banco de dados. O scala está avançando nisso com o slick, que embora não seja padrão da linguagem é pelo menos possível. O java simplesmente não tem esta feature. É que esta feature precisa da ajuda do compilador para fazer algumas mágicas e produzir um ExpressionTree – que é a arvore de instruções que foram dadas dentro dos lambdas – que opera como um reflection de lambdas. Mas a verdade é que o java não precisa disto. Sempre foi possível escrever builders de SQL em java., o que os lambdas vão trazer é uma facilidade para escrever builders mais fluentes. O java tem o JPA e o Hibernate e um conjunto de outras API esparsas que se beneficiariam de uma linagugem de query comum, contudo isso também os limitaria.
O LINQ como ferramenta que se utiliza do compilador para produzir código especial é fanática, mas o tempo que a microsoft gastou em um compilador que entende monads e expression trees não foi usado em apurar o sql que é gerado, ou as features que seriam interessantes e ja existem no hibernate e no jpa (como UserType). A verdade é que embora o LINQ seja fantastico, o univeros java pode viver bem sem ele. Outras coias mais importantes teriam que acontecer primeiro, com a reificacão de generics em vez de erasure (que aliás é um requisito importante para features como o LINQ e extension methods)
Como eu falei antes a batalha das linguagem já foi ganha pelo scala, mas a batalha pela api e plataforma ainda é do java. Todas as linguagens da JVM querem se integrar com a API padrão do Java para tirar proveito da quantidade absurda de bibliotecas para os mais diversos fins. E por isso, o objetivo de é melhorar essas API é tão ou mais importante que a linguagem em si. No fim a Oracle fez bem em esquecer a concorrência e lançar coisas que e os outros não têm. A nova api de datas é a melhor api de datas de todas as plataformas. O novo check Framework é muito bem vindo e uma lufada de ar fresco.
Uma outra funcionalidade nova no Java 8 são os virtual Extension Methods, também conhecidos como Defender Methods. Esta funcionalidade permite estender a sua – a apenas a sua – api de forma retrocompativel. O exemplo clássico é a interface List. Seria fácil à Oracle adicionar um novo método na interface, mas isso faria com que todo o mundo que implementa essa interface não compilasse mais porque lhe falta um método. Os Defender Methods permitem declarar uma implementação padrão, que será usada caso a classe real não implemente o método. Dessa forma a Oracle pode colocar os métodos que quiser, onde quiser, sem nunca quebrar a compatibilidade. Isto é muito bom, mas o ranço que fica no ar é que apenas quem detém o código fonte que pode estender os tipos. Se você quiser colocar um método em List, você continua não podendo. Esta forma de adicionar métodos em classes e interfaces é pobre comparada com outras opções como as Extensions do C# , o using do Haxe ou oaté implicit conversion do Scala (que implica em criar um decorator, mas pelo menos permite estender as classes que não são nossas). Defender methods é uma coisa que não foi levada às ultimas consequências e na minha opinião é uma não-solução. Claro que alguém pode argumentar entre ter defender methods e não ter, é melhor ter. Sim. Mas seria melhor ter algo mais útil para o dia a dia e não apenas para quem desenha API. Como criador de API (como o MiddleHeaven) é muito bom contar com esta funcionaldiade, mas como usuário de API era melhor ter uma forma mais geral como as do C#, Haxe , Scala, etc…
Eles sabem que o Java 8 é um paliativo a ver pelo que vem por ai (Roadmap do java 9 e 10) , mas se pensarmos na quantidade e qualidade de coisas novas e boas que chegaram no Java 8 face ao que poderia ter sido feito melhor , as novas funcionalidades ganham.
Um ponto importante é que junto com o JSE 8 foi lançado o novo JME 8 que o novo Java 8 Embeded que prometem chacoalhar o mundo dos embarcados. O Java 8 embeded já corria em Raspery PI antes do JSE ser lançado, e à medida que as pessoas se habituarem à nova sintaxe e funcionalidades vai ser ainda mais fácil criar aplicações para dispositivos embarcados. O JM8 também evolui muito aproximando a linguagem de forma que não temos que programar embarcado com uma versão “mais pobre” da linguagem. Apenas com uma versão mais simples da API.
Ha muita coisa para aprender e vale a pena dar uma olhada na lista de melhorias do Java 8
Parabéns Sergio, post fantástico como sempre, espero que continue postando.
Você acredita no renascimento do java, que as próximas versão sejam revoluções (assim como a 8) e não apenas evoluções?
Espero que a Oracle e o JCP se esforcem, e implementem novas features que tragam poder e simplicidade, como a reificação dos generics, literais para collections, etc.
E o que você acha da sobrecarga de operadores, seria ótimo por exemplo pra trabalhar com BigInteger e BigDecimal.
Até mais.
Obrigado pelo incentivo Douglas.
A Oracle está preparando algumas coisas que podem realmente ser revolucionárias para o java 9 e 10. A lista de possibilidades dá pelo nome de JEP (Java Enhancements Proposal)
Estas são alterações ao java que depois irão viram jcp. O meu medo é com o cronograma disto tudo. O processo java é mais acadêmico que o do .net , por exemplo, e isso leva a resultados melhores, mas também a um periodo maior. Reificação , por exemplo, é algo bem complexo. O .net optou pelo caminho mais simples e rápido a custo de sacrificar a retro-compatibilidade. No java, isso não é uma opção, então o caminho tem que ser outro.
A sobrecarga de operadores é realmente interessante. No Scala é possivel definir operadores com quaisquer nomes e isso leva a um código muito cheio de simbolos e portanto dificil de entender. Um das diretivas do java é que o código tem que ser legivel. Logo o abuso de símbolos não deverá ser um opção. Uma opção mais interessante seria algo como o Grovy faz onde cada símbolo corresponder a um método. Esta é a forma mais simples que eu acho que poderia ser utilizada. Inclusive o Groovy usa isso para poder aproveitar os metodos que já existem em BigDecimal e BingInteger. Se a sobrecarga for incluida ele também deverá ser retroativa de forma a poder ser usada em objetos que já foram definidos antes (se bem que com os defender methods isso não seria uma obrigação, mas seria interessante). Outra coisa que seria interessante seria metodos indexadores para poder usar a sintaxe [i] em objetos outros que não apenas arrays. Seria util para objetos de libs matemáticas que usem vetores e matrizes.
O java 9 deve sair com o mecanismo de modulos (jigsaw) que também é muito interessante. A linguagem Ceylon já vem com isso incluido na linguagem. O java vai ter usar anotations e artificios especiais para criar esses pacotes, mas espero que seja vem util. Também muito do que se está fazendo no SE é para criar um EE melhor mais virado para cloud e multytenant, então acho que o futuro nos reseva muitas boas surpresas. Isso é bom, mas também é o problema em si: ter que esperar. 😉
Obrigado Sergio, realmente o problema é a espera.
No roadmap da Oracle, o Java 8 iria ser lançado em 2013, e o Java 9 em 2015, houve um atraso e então o Java 8 foi lançado em 2014, então provavelmente o Java 9 seja lançado em 2016.
Até mais.
Sergio, com o Jigsaw será possível modularizar o próprio JDK?
Por exemplo, definir módulos onde se “exclui” APIs pouco utilizadas, ou classe depreciadas como java.util.Date ou outros pacotes que não serão utilizados na aplicação?
Até mais.
Sim. O jigsaw ira modularizar a jvm e o jdk,mas tambem ira permitir fazer o mesmo com os nossos aplicativos. É uma evolucao em cima do osgi. A politica de deprecated parece que vai ficar mais forte com a marcação acontecevdo na versao N e remoção na versao N+1. A api esta ficando melhor,mais afinada com o mundo real.A minha sensação é que finalmemte se abriram as portas para coisas que a sun nunca quiz fazer. Vem muita coisa boa por ai. Tanto na linguagem, api e no jee.
Sérgio, a Microsoft acaba de liberar boa parte do .NET como opensource e também multiplataforma, será que isso pode impactar de maneira significativa a adoção do Java?
Olá Douglas,
A Microsoft realmente está trabalhando numa nova versão do .NET que será open source e que rodará em linux. Isto não impacta em nada o Java quanto a mim. O forte do java é JEE que a plataforma .NET simplesmente não tem. Não existe nada semelhante a um EJB container no mundo .net e isso é a diferença. A Microsoft esta fazendo o que ela faz melhor, saqueado/sacaneando a Xamarim (outra vez) e tomando o mono para si. A Xamarim tb estava entrando no mundo iOS e Android com a sua compilação cruzada e a microsoft quer um pedaço desse mercado (pois o windows phone é um fiasco comparado a esses dois). Para mim é um misto entre controle de expansão do .net fora do windows ao mesmo tempo que acena com a bandeira do open source. Contudo alguém realmente acredita que isso vai durar ? As experiencias passadas com o apoio ao Mono e às linguagens Iron (IronRuby e IrroPython) que eram ports de outras linguagens para o .net foram abandonadas um tempo depois do anuncio do apoio. Será que desta é diferente ? vamos ver.
Se realmente vingar isto pode significar mais aplicações desktop sendo criadas (clientes ricos) pois o forte to .net ainda é windows forms. Na parte web, tanto faz usar .net ou java (embora .net pode ser mais caro de manter). Na parte server concerteza java ou até coisas mais novas como noje.js ganham do .net. A Oracle também não está dormindo no ponto e 2016 vai ser um ano interessante com a saída do java 9 (se não atrasar como o java 7) e do .net 4.6.
Por outro lado, para que o .net vingue no linux é preciso mais do que a plataforma rodar em linux. Por exemplo, é necessário que o LINQ to SQL funcione com postgress , por exemplo ( o que hoje não acontece).
Eu venho trabalhando com c# .net estes últimos anos e como linguagem o C# é bom o suficiente. O problema está mais na plataforma. Hoje tudo depende de serviços windows para coisas que no java estão no EE como transações distribuídas ou mensageria. Portanto, o porte para linux vai nos mostrar como o .net não precisa do windows , o que é contrassenso ao status quo de hoje. Mas estou curioso para ver o que dá. Se vingar, ótimo, a concorrência nunca fez mal a ninguém. Pode ser até que linguagens novas como scala, kotlin ou ceylon migrem mais rapidamente para .net também. Se não vingar … bom, afinal terá sido só uma manobra mediatico-politca da microsoft (nada de novo nisso)