Enquanto no Brasil se comemorava o Carnaval, a galera do JCP passava por uma semana, no mínimo, conturbada. Isso porque no último dia 23 encerrava-se a votação da JSR-316, a qual define o novo padrão para a Java EE.
Como era de se esperar, cada entidade participante berrou um pouco querendo puxar mais brasa para o seu assado.
Mas então, quais foram os comentários da votação?
Os gigantes falando
Dos 16 integrantes, a Apache Foundation, foi a única que votou contra. E por quê?
Porque ela não concorda com as regras que balizam o TCK, que é o framework utilizado para homologar produtos que desejam ganhar o selinho Java EE.
Na prática, o argumento da Apache é que o esquema de licenciamento do TCK é restritivo e obscuro em alguns pontos, fazendo com que empresas que desejam homologar seus produtos ficam, por vezes, limitadas sob a édige da Sun.
A Red Hat, notável defensora do Open Source sustentável deu um Sim para a especificação mas fez um comentário forte, reclamando da posição da Sun sobre o famigerado TCK e o seu esquema de licenciamento.
A IBM, que defende o Open Source mas também tem produtos fechados, deu uma resposta clara para Red Hat (é interessante olhar as datas em que cada um postou seus comentários) , dizendo que a JSR (e por consequencia, o posicionamento do JCP) deve ter mérito técnico, e não político. Assim, de um Sim para o padrão.
A SAP votou sim, e também se posicionou como a Red Hat, querendo uma política de licenciamento do TCK mais clara. Ainda, salientou que gostaria de ter um maior detalhamento na JSR, enfatizando que as "bordas" da arquitetura precisam ter definições mais precisas, evitando coisas como (ela não usou esses termos) XML proprietários adicionais dentro de componentes Java EE para que as coisas realmente funcionem em ambientes reais.
O pessoal do Spring votou Sim, mas reclamou também. Como o foco desse povinho é a web, eles não poderiam deixar de falar mal da abordagem que foi dada para os Profiles Web na especificação, os quais (segundo eles) ficaram em segundo plano.
Ainda (e isso concordo com eles), disseram que a injeção de recursos deveria ser tratada no Java SE, e não somente em ambiente Enterprise.
Por fim, deram uma espetada (claro) no trabalho do nosso amigo Gavin King, dizendo que colocar tecnologias "muito novas" (como a JSR 299) dentro da especificação pode ser um tiro no pé. Reclamaram também dizendo que o resultado da especificação ficou distorcido em relação a proposta inicial.
O pessoal da Intel disse Sim, e fez um comentário geral ressaltando novamente o tema TCK e a dependência indireta da Java EE em relação ao (TCK da) Java SE. Enfatizou que um trabalho no sentido de tornar o TCK da Java EE independente da (TCK da) Java SE seria muito interessante e a Apache Foundation deveria se preocupar mais com isso (do que votar contra).
O resto da galera "apenas" votou ou absteve-se.
Conclusões
Baixei o draft da especificação hoje novamente, para ve se teve grandes ajustes em relação ao Early Draft que eu havia baixado em Outubro. Acredito que não.
O que é interessante notar nesses comentários é o forte posicionamento de cada empresa para que seu nicho de mercado seja melhor contemplado pela nova especificação.
Enquanto a Red Hat deseja modelos Open Source, empresas como IBM e Oracle não querem tanto isso, visto que algumas linhas de seus produtos se beneficiam justamente nesta parte.
A galera do Spring, como sempre, tenta rivalizar com o JCP (e vejam bem: eles fazem parte do JCP!), pensando muito na web. Se assim fosse, poderíamos ver o Google brigando por conectores para mobile para a sua plataforma Android, mas não é isso que ocorre em cenários semelhantes...
Concordo porém com o Spring no sentido de que a injeção de recursos deveria ser tratada diretamente no Java SE, olhando trabalhos interessantes, como o Google Guice e outros.
Mas discordo novamente com a aversão deles em relação ao Web Beans (que na verdade é Contexts and Dependency Injection for Java). Acredito sim que o Web Beans (acho que este nome vai ser difícil de esquecer) é um canhão para matar moscas e poderia ter uma softwaresfera somente para ele; mas discoro da posição do SpringSource porque eles birram com o Web Beans devido ele ter evoluiu rápido e ganhado mais espaço que o Spring. Então, corram meninos do Spring para tirar o atraso, e não fiquem reclamando da brasa que os outros puxam.
Por fim, acho que a Java EE 6 é grande pacas. Mas o mundo é assim. Em 8 anos de Java EE, muitas especificações surgiram e tomaram corpo. Cada qual ganhando terreno em uma área. Mas na prática, esta versão 6 não traz nada de muito novo não (exceto o Web Beans e os Profiles).
Tenho medo sim da versão 7, que provavalmente vai incorporar uma nova sintaxe de linguagen e empacotamento (JSR 294) para o Dolphin, o suporte a linguagens dinâmicas, e quiçá elementos de barramentos ESB.
Que berrem e que chutem, mas que façam um bom assado para nós pobre programadores usuários de uma linguagem fétida (como diria meu amigo L.).
Como era de se esperar, cada entidade participante berrou um pouco querendo puxar mais brasa para o seu assado.
Mas então, quais foram os comentários da votação?
Os gigantes falando
Dos 16 integrantes, a Apache Foundation, foi a única que votou contra. E por quê?
Porque ela não concorda com as regras que balizam o TCK, que é o framework utilizado para homologar produtos que desejam ganhar o selinho Java EE.
Na prática, o argumento da Apache é que o esquema de licenciamento do TCK é restritivo e obscuro em alguns pontos, fazendo com que empresas que desejam homologar seus produtos ficam, por vezes, limitadas sob a édige da Sun.
A Red Hat, notável defensora do Open Source sustentável deu um Sim para a especificação mas fez um comentário forte, reclamando da posição da Sun sobre o famigerado TCK e o seu esquema de licenciamento.
A IBM, que defende o Open Source mas também tem produtos fechados, deu uma resposta clara para Red Hat (é interessante olhar as datas em que cada um postou seus comentários) , dizendo que a JSR (e por consequencia, o posicionamento do JCP) deve ter mérito técnico, e não político. Assim, de um Sim para o padrão.
A SAP votou sim, e também se posicionou como a Red Hat, querendo uma política de licenciamento do TCK mais clara. Ainda, salientou que gostaria de ter um maior detalhamento na JSR, enfatizando que as "bordas" da arquitetura precisam ter definições mais precisas, evitando coisas como (ela não usou esses termos) XML proprietários adicionais dentro de componentes Java EE para que as coisas realmente funcionem em ambientes reais.
O pessoal do Spring votou Sim, mas reclamou também. Como o foco desse povinho é a web, eles não poderiam deixar de falar mal da abordagem que foi dada para os Profiles Web na especificação, os quais (segundo eles) ficaram em segundo plano.
Ainda (e isso concordo com eles), disseram que a injeção de recursos deveria ser tratada no Java SE, e não somente em ambiente Enterprise.
Por fim, deram uma espetada (claro) no trabalho do nosso amigo Gavin King, dizendo que colocar tecnologias "muito novas" (como a JSR 299) dentro da especificação pode ser um tiro no pé. Reclamaram também dizendo que o resultado da especificação ficou distorcido em relação a proposta inicial.
O pessoal da Intel disse Sim, e fez um comentário geral ressaltando novamente o tema TCK e a dependência indireta da Java EE em relação ao (TCK da) Java SE. Enfatizou que um trabalho no sentido de tornar o TCK da Java EE independente da (TCK da) Java SE seria muito interessante e a Apache Foundation deveria se preocupar mais com isso (do que votar contra).
O resto da galera "apenas" votou ou absteve-se.
Conclusões
Baixei o draft da especificação hoje novamente, para ve se teve grandes ajustes em relação ao Early Draft que eu havia baixado em Outubro. Acredito que não.
O que é interessante notar nesses comentários é o forte posicionamento de cada empresa para que seu nicho de mercado seja melhor contemplado pela nova especificação.
Enquanto a Red Hat deseja modelos Open Source, empresas como IBM e Oracle não querem tanto isso, visto que algumas linhas de seus produtos se beneficiam justamente nesta parte.
A galera do Spring, como sempre, tenta rivalizar com o JCP (e vejam bem: eles fazem parte do JCP!), pensando muito na web. Se assim fosse, poderíamos ver o Google brigando por conectores para mobile para a sua plataforma Android, mas não é isso que ocorre em cenários semelhantes...
Concordo porém com o Spring no sentido de que a injeção de recursos deveria ser tratada diretamente no Java SE, olhando trabalhos interessantes, como o Google Guice e outros.
Mas discordo novamente com a aversão deles em relação ao Web Beans (que na verdade é Contexts and Dependency Injection for Java). Acredito sim que o Web Beans (acho que este nome vai ser difícil de esquecer) é um canhão para matar moscas e poderia ter uma softwaresfera somente para ele; mas discoro da posição do SpringSource porque eles birram com o Web Beans devido ele ter evoluiu rápido e ganhado mais espaço que o Spring. Então, corram meninos do Spring para tirar o atraso, e não fiquem reclamando da brasa que os outros puxam.
Por fim, acho que a Java EE 6 é grande pacas. Mas o mundo é assim. Em 8 anos de Java EE, muitas especificações surgiram e tomaram corpo. Cada qual ganhando terreno em uma área. Mas na prática, esta versão 6 não traz nada de muito novo não (exceto o Web Beans e os Profiles).
Tenho medo sim da versão 7, que provavalmente vai incorporar uma nova sintaxe de linguagen e empacotamento (JSR 294) para o Dolphin, o suporte a linguagens dinâmicas, e quiçá elementos de barramentos ESB.
Que berrem e que chutem, mas que façam um bom assado para nós pobre programadores usuários de uma linguagem fétida (como diria meu amigo L.).
3 comentários:
Muito bom o seu blog, conheci há pouco.
Gostei dos detalhes trazidos por ti.
Está de parabéns.
Já adicinei o blog no meu leitor RSS.
Abraço.
ps:"linguagem fétida"? Então por quê trabalha com ela? Acho melhor mudar para ruby ou python então, já que essa "linguagem fétida" não o agrada.
Ahah,
Valeu pelo retorno...
Linguagem fétida é um termo que meu amigo, o "Luis Fétido" usava pra se referir a qualquer linguagem de programaçao, onde nós desenvolvedores brigamos diariamente com ela, hehehe.
Abracos.
ps. Tbm olhei seu twitter...
rsrsrs, desculpe pelo engano, Marcelo.
É que eu adoro Java e fico meio puto quando começam a falar mal e dizem que o ruby é a solução pra tudo.Ambas possuem pontos fortes e fracos.
Se você tiver twitter passa aí o link, não consegui achar.
Abraço.
Postar um comentário