Java 8 – Pr√≥logo 

Apr/14
17

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

7 comentários para “Java 8 – Pr√≥logo”

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

  2. 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. ūüėČ

  3. 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.

  4. 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.

  5. 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.

  6. 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?

  7. 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)

Comente

Artigos