Como venho acompanhando e escrevendo, a JVM caminha cada vez mais para um modelo multi-linguagem próximo do que o .Net tinha como proposta inicial. Uma apresentação de Grahan Hamilton no JavaPolis 2006 recentemente disponibilizada sobre o futuro da plataforma menciona que já no Dolphin (Java 7, próximo lançamento após o Mustang/Java 6) o suporte à linguagens dinâmicas diretamente no bytecode deverá ser incluído.
Por que isso é tão importante?
Porque é a primeira vez bytecode não utilizado pela linguagem Java é inserido na plataforma Java. Não haveria mais como negar a separação entre as duas coisas.
Se a JVM quer ser a plataforma o futuro (sinto decepcionar tanta gente mas Java é a plataforma do presente faz um tempinho), precisa se adaptar às novas realidades. Java não é a melhor ferramenta sempre: muitas vezes ela é complexa demais (perde para PHP ou Ruby on Rails), muitas vezes é inflexível (perde para Ruby, Python, Smalltalk e LISP) e muitas vezes exige um nível de conhecimento técnico não disponível em uma empresa (perde para VisualBasic, Delphi e PowerBuilder).
Há um bom tempo a Microsoft juntou várias idéias já existentes vindas de Java, Delphi, PERL 6, (o embrião de) Java EE, C++, J++, Visual Basic, DirectX, Applets, XML, etc, etc e misturou tudo no seu .Net. O grande problema na minha opnião é que o maior diferencial da plataforma nunca foi explorado.
Enquanto Java suportava oficialmente uma linguagem e implementar qualquer outra era (possível mas) extremamente trabalhoso, .Net já vinha com uma estrutura para suportar várias linguagens. As linguagens em sí não eram nenhuma novidade, até PERL já tinha algo assim em 2001, mas o apoio de uma organização do tamanho da MSFT colocando máquinas virtuais multi-linguagem na maioria dos computadores do mundo era algo muito interessante.
Mas o mercado de .Net se dividiu em 2: C# para o Elvis, VB para o Mort. Todo mundo usa ASP.Net assim como desenvolvedor Java geralmente (mas nem sempre) usa JSP para conteúdo web.
Então toda aquela diversidade de linguagens simplesmente sumiu. Hoje a Microsoft tenta correr atrás do prejuízo aumentando o suporte à linguagens como IronPython mas neste meio termo pessoas e empresas que investem na JVM ou apenas desejam usar uma VM comercial menos restrita já criaram alternativas (como Jython).
O mesmo está acontecendo com MDA vs. Software Factories. Redmond comprou a idéia (e o passe) de um cara que trabalhava na IBM chamado Jack Greenfield que é um contrapotno ao MDA em diversos aspectos. A idéia original é a mesma: Model Driven Design. Se você não sabe o que é, imagine por enquanto que se trata de colocar um modelo -sejam diagramas UML ou qualquer outro tipo de notação de alto nível para modelagem que não uma linguagem de programação como Java ou C#- num compilador e este gerar não só código mas o sistema inteiro. Não, não é o mesmo que CASE, mas para isso precisamos de um artigo próprio.
O Model Driven da MSFT se difere do do OMG/IBM principalmente no fato de não usar UML. A primeira vez que vi esta discussão eu achei que era apenas mais uma tentativa da Microsoft de vender uma linguagem proprietária de modelagem mas depois percebi que não era apenas isso.
Lembra lá em cima quando disse que Java não é a melhor ferramenta para todos os problemas? Bem, UML também não é. UML foi construída para ser flexível mas suas raízes em ser uma linguagem para ‘documentação e modelagem de sistemas de software orientados a objetos’ é bem visível.
Se é apenas uma questão de levantar o nível de abstração ok, podemos utilizar uma linguagem genérica. O grande problema nesta alternativa para mim é que (tirando outras características dos compiladores de modelo MDA como teórica independência de arquitetura no produto final) estamos apenas substituindo uma linguagem como Java por uma notação gráfica com o mesmo propósito: ser uma linguagem de programação genérica.
A proposta da Software Factory para este problema das linguagens é ao invés de UML/Java/C# utilizarmos uma linguagem específica para aquele problema. A linguagem não precisa ser gráfica mas deveria fazer sentido dentro do domínio, os construtos e primitivas dela devem ser conceitos daquele domínio. Nada abstrato e genérico como um StringBuffer, coisas como Tabelas, Conta, Fluxo, Pedido… estão são as Domain Specific Languages (DSLs).
Ainda é cedo para saber qual modelo vai vingar. Eu voto hoje num modelo híbrido com a parte de DSLs da Microsoft, a padronização e os compiladores do MDA. Quando Java EE 1.3, 1.2, etc trazia (traz!) aquele monte de XML a Microsoft desenvolveu um sistema de metadados de serviços. Tantos anos depois Java EE 5 bebe da mesma fonte mas aplica melhores práticas de desenvolvimento.
E agora, com maior abertura para novas linguagens, Java se aproxima mais das DSLs. Que bom!
Não dá pra ignorar o que vem da Microsoft ‘porque é da Microsoft’. De Redmond saem muitas coisas ruins mas ocasionalmente saem coisas boas. Como eu li em algum lugar na Internet dia desses “a Microsoft tem desenvolvedores brilhantes, o problema dela deve ser os gerentes”.
Mesmo assim, a MSFT não é a única a investir neste ramo. Fowler fala mais sobre isso num paper recente que, aliás, deve ser lido por qualquer um interessado no tema.
