Resolvido conflito entre JSR's de Injeção de Dependência

Deu na InfoQ. Foi resolvido o conflito entre as duas JSR's que propõe padronização de injeção de dependência em Java. Para quem não tem acompanhado esta novela segue um pequeno resumo. Há mais de dois anos surgiu a JSR 299 com o nome de WebBeans, cujo o escopo , segundo a especulação inicial, era padronizar o Seam. Porém com a evolução da especificação ficou claro que a proposta na verdade era padronizar o conteiner de de injeção de depêndencia do Seam para platataforma JEE tendo em vista que os recursos que este prove estão bem além dos providos pela especificação JEE5. Muito tempo depois, duas empresas de fundo de quintal, uma tal de Google e SpringSource resolveram unir forças para padronizar o que aprenderam nos seus fremeworks de injeção de dependência, respectivamente Guice e Spring , e assumiram a liderança da JSR 330 a fim de padronizar o Serviço de Injeção de Dependência no ambiente Desktop(JSE). Minha impressão eh que essa historia de DI em ambiente JSE foi apenas uma jogada política dos dois Big-Players para ganharem espaço e poder de decisão, pois pra quem conhece um pouco de injeção de dependência fica claro que uma proposta para um ambiente atende ao outro com pouco ou nenhum esforço e/ou DI em JSE seria subset do JEE. O fato eh que por algum tempo, até recentemente, coexistiram duas propostas de JSR para DI que não se conversavam. Eis que a InfoQ anuncia que o embate foi harmonizado de forma que, adivinhem, a 299 vai usar a 330. Espero que a modularização em Java que anda as voltas em JSR's de numéros exóticos como 277, 291, 294 e nomes como OSGI , HK2 e Project Jigsaw tenha um final feliz também.

java.io.NotSerializableException e a flag -Dsun.io.serialization.extendedDebugInfo=true

Estávamos com um grande problema de serialização, em que uma classe que, a princípio, não tinha relação nenhuma com as demais estava dando serializada, dando:
java.io.NotSerializableException
Como ela nem deveria estar sendo serializada precisávamos descobrir o que estava pedindo que ela fosse serializada. No entanto, não foi possível entrar no código com Debug. Mas, a própria classe de serialização fazia um debug mais profundo através da flag:
-Dsun.io.serialization.extendedDebugInfo=true
Habilitando esta flag colocando-a nos argumentos da VM, voltamos a serializar sem problemas.

Gerenciamento de exceções no Eclipse RCP

Muitas vezes o eclipse passa batido nas RuntimeExceptions.

Isto ocorre porque o tratamento delas é feito no WorkbenchAdvisor, no método eventLoopException(Throwable). Para que isso não aconteça é necessário dar um override nesta função, geralmente no ApplicationWorkbenchAdvisor, algo como:

public void eventLoopException(Throwable exception){
     System.out.println("Override do eventLoopException");
exception.printStackTrace();
super.eventLoopException(exception);
}

[]'s

Atalhos do Eclipse

Caros,

Como diria o nosso instrutor quando do curso de Arquitetura Java: "Mouse dá choque!" Então, vão aqui alguns links com os principais atalhos do Eclipse que todos nós deveríamos saber (mas não sabemos!):

10 Eclipse Navigation Shortcuts Every Java Programmer Should Know

Eclipse Shortcuts

Abraços!

Notas de um Desenvolvedor Eclipse

Caros,

O Blog Lubos Eclipse Weblog iniciou como um repositório de informações sobre como fazer plugins e aplicações RCP com Eclipse. Lá ele juntou várias dicas, sites, tutoriais sobre os mais diversos aspectos desse tipo de programação. Com certeza quem programa para eclipse não vai se arrepender de dar uma olhada!

Frase da Semana de 5 à 11/07

"... if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy" . Essa é do James Strachan, "O Cara" de Groovy. Esta me motivou a tirar o meu exemplar do referido livro da estante e iniciar um pet project, que há tempos venho bolando, e que pretendo fazer em Scala, a fim de consolidar meus conhecimentos nessa linguagem tão comentada de uns tempos pra cá no meio geek.

Frase da Semana 14 a 20/06

"...we really are moving more and more down the road of declarative development. Over time we will see more "what" and less "how" in our day to day programming adventures."

Gostei muito dessa frase, ainda que não tenha tanta fé quanto o autor do post que programação declaratival se torne paradigma mainstream, mesmo tendo sql o seu lugar ao sol. Essa minha conclusão é muito eu-cêntrica, pois atualmente tenho trabalhado com hql e jpaql e tenho sentido alguma dificuldade em quebrar as amarras imperativas do meu cérebro, porém quando o consigo fazer fico extremamente satisfeito com o produto, pois código declarativo, como disse o autor do post, é focado em "o que" e não "como", o que deixa o código mais sucinto e claro. Cá entre nós, eu acho mais difícil pensar declarativamente, não sei se porque venho de uma escola imperativa ou se é realmente mais fácil persar em if's, for's e com assinalação destrutiva do que com and's, or's, recursividade e imutablidade. Talvez seja, como quase tudo na vida, uma questão de prática.

Só uma última coisa, o código do exemplo do post é em C# e dá uma tristeza em ver quanto Java tá comendo poeira quando comparada com a sua concorrente da Microsoft. No entanto é legal ver que dá para fazer Link em Scala sem adicionar palavras reservadas na linguagem, que foi a estratégia usada em C#.