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