Java precisa de classes abertas

13nov07

Open WindowsNão é muito complicado encontrar por aí propostas para tornar Java – a linguagem – mais moderna, com adições de recursos muito úteis em outras linguagens. Hoje o Bruno Borges propôs uma alteração para realizar return do objeto this de maneira mais direta, basicamente é sintax sugar com uso restrito. Algumas semanas atrás foi liberada uma versão preliminar de closures para Java e surgem RFE aos montes para melhorias aqui e acolá. Apesar da evolução benéfica causada pela concorrência com .Net, como linguagem, Java tem boa resistência a adições, além de boa parte delas estarem atrasadas faz algum tempo. Mas não porque outras linguagens foram mais competentes, acontece que há uma diferença muito grande entre nascer com closures e inclui-las depois. Para Java, o atraso fica evidente por causa da imensa quantidade de APIs, frameworks, etc feitos até agora sem que os desenvolvedores pudessem lançar mão dos novos recursos. Quer um exemplo? As APIs de Collections e IO estão congeladas em zero absoluto e ninguém vai se atrever a colocar um novo método sequer em java.util.Collection porque isso quebra código em uma quantidade impraticável.

Essa inércia nos direciona para código pouco interessante, pois metodos como “each“, “findAll“, “collect” seriam estáticos, provavelmente jogados em java.util.Collections. Entretanto, há uma adição que tornaria a adoção de todas as outras mudanças bem mais simples: classes abertas. Classes abertas são uma maneira de evoluir as APIs por fora sem quebrar código existente. .Net tem corrido atrás de algo semelhante usando extension methods e talvez seja a hora de Java tomar – novamente – algumas idéias emprestadas com a concorrência. Esse tipo de recurso também permite que passemos por cima de pequenos erros de design e possamos, por exemplo, transformar isso:

Date now = new Date();
Calendar temp = Calendar.getInstance();
temp.setTime(now);
temp.add(Calendar.MINUTE, minutes);
Date newDate = temp.getTime();

Nisso:

Integer two = 2;
Date now = new Date();
Date newDate = now.add(two.minutes());

Acredite, não é sobre quantidade de linhas, mas sobre clareza e expressividade. Claro, isso envolve outras discussões como interfaces humanas vs interfaces mínimas (a estratégia usada em Java). Só que as “alterações” nas classes não precisariam estar dentro do API padrão, mas sim em código escrito pelos desenvolvedores ou em bibliotecas de terceiros. Estes sim seriam responsáveis por “mover” para java.util.Collection código que com certeza entrará em alguma classe com trocentos métodos para manipular coleções. “De qualquer modo”, talvez seja melhor pensar em outras frentes, especialmente na evolução de Java como plataforma pode oferecer melhor suporte para a infinidade de linguagens disponíveis para a JVM.

About these ads


4 Responses to “Java precisa de classes abertas”

  1. Creio que criar fluent interfaces para a API java e submeter tal código como melhoria / adendo à API existente já seria um bom passo para termos uma API mais usável e legível.

    Acho que o pessoal que propõe mofificações em linguagem não está preocupado em melhorar a linguagem, mas equiparar recursos de outras linguagens afim de que as pessoas continuem escrevendo seus códigos em java, como se o código só nela fosse o suficiente para tudo, conceitualmente falando

    T+

  2. Gláucio, submeter código para apis padrão implica criar uma JSR, o que é um processo bem mais trabalhoso do que criar um projeto open source, por exemplo. Se forem partes muito usadas da API, como a de collections que citei, a JSR não passa. Entretanto, com classes abertas esses projetos open source poderiam simplesmente injetar métodos dentro da api padrão.

    Sobre modificações na linguagem, concordo com vc: o ideal é se tornar poliglota ao invés de querer fazer tudo em Java, sempre.

    valeuz…

  3. Sim, mas nada impede deles trazerem fluent interfaces como adendo à maneira de chamar as coisas. Isso não vai quebrar o que está feito, é só uma maneira diferente de ler a mesma coisa que foi escrita. Acho que não passa pelo fato deles não considerarem esse tipo de mudança relevente para a API, já que eles tem essa filosofia de interfaces mínimas.

    T+


  1. 1 Surpresa: Extension Methods para Java « Motor Curiosidade

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s


Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

%d blogueiros gostam disto: