Veille technologique semaine 45

Pour le bulletin de cette semaine, je vous propose les sujets suivants :

• le futur de Java par Google
• la communication entre les architectes et les développeurs
• l'injection de dépendances avec JEE6
• les optimisations du compilateur JIT par défaut pour le JDK 7
• l'outil Sonar et les métriques sur la qualité du logiciel
• des designs pattern d'instanciation d'object en Java
• l'outil VisualVM qui passe en version 1.2
• JUnit : annotations vous avez dit annotations ?
• le mélange des composants "lourd et léger" en Java : pour les IHM.

Bonne lecture .

The Future of Java

• Project Coin
• JSR-330: Dependency Injection for Java

Turtles and Architecture
Many of us can relate. In dysfunctional organizations, architects and
developers fail to communicate effectively. The result is a lack of
transparency and a lack of understanding by both sides, as shown in
the diagrm (click to enlarge). The failure often occurs (though I
recognize there are other causes) because architecture is about
breadth and development is about depth. Each group has disparate
views of software architecture, and while both are warranted, a gap
between these views exists. The architect might focus on applications
and services while the developer focuses on the code. Sadly, there is
a lot in between that nobody is focused on. It is this gap between
breadth and depth that contributes to ivory tower architecture.


Dependency Injection in Java EE6 - Part 1
This series of articles introduces Contexts and Dependency Injection for Java EE (CDI), a key part of the soon to be finalized Java EE 6 platform. Standardized via JSR 299, CDI is the de-facto API for comprehensive next-generation type-safe dependency injection for Java EE. Led by Gavin King, JSR 299 aims to synthesize the best-of-breed dependency injection features from solutions like Seam, Guice and Spring while adding many useful innovations of its own.


Les optimisations du JDK 6u14 activées par défaut sur le JDK 7
Rémi Forax, un contributeur sur OpenJDK et sur la JSR-292, a fait part
de son étonnement en constatant un gain significatif de performance
entre deux builds successifs de l'OpenJDK 7 actuellement en cours de
développement. C'est ainsi qu'il a pu se rendre compte que deux
optimisations majeures du compilateur JIT de la JVM étaient activées
par défaut depuis le build 72 du projet : l'escape analysis et la
compression de pointeurs. Celles-ci étaient apparues dans le JDK 6u14
mais n'y étaient pas activées par défaut.

Pour rappel l'escape analysis consiste en l'analyse du bytecode d'une
méthode pour découvrir les références vers les objets qui ne «
s'échappent » pas du contexte de la méthode. Grâce à cette analyse, la
JVM peut alors décider d'allouer ces objets directement sur la stack
plutôt qu'en heap comme c'est normalement le cas. Il en résulte un
gain de performance évident puisque le coût d'allocation et de
libération de mémoire est alors supprimé pour ces objets.

La compression de pointeurs, quant à elle, concerne uniquement les JVM
64 bits. En effet le passage d'un adressage de 32 à 64 bits entraîne
une consommation plus élevée de la mémoire du fait de l'augmentation
de la taille des pointeurs, induisant elle-même des temps de
chargement plus longs et une surconsommation du cache du processeur.
Pour palier ce problème, la compression de pointeurs se base sur le
fait que la JVM aligne l'adresse des objets sur 64 bits (ceci afin de
simplifier et donc d'accélérer leur accès en mémoire), pour procéder à
un scaling des pointeurs. Ainsi, en limitant l'espace mémoire
adressable à 32 Go, il est possible de contenir un pointeur dans 32
bits et donc de revenir à une consommation mémoire proche de celle
d'une JVM 32 bits.

L'activation par défaut de ces deux optimisations sur le JDK 7 montre
que l'équipe du projet estime désormais qu'elles ne sont plus
expérimentales et qu'elles conviennent dans la majorité des cas.
Ismael Juma précise par ailleurs qu'il est possible que ces
activations par défaut soient reportées également au JDK 6 courant 2010.



Contrôles de qualité avec Sonar
La qualité d'une application étant directement liée à la qualité de son code, de nombreux outils sont apparus pour effectuer différents contrôles : reporting de tests unitaires, analyse de la couverture du code par les tests, vérifications du respect des règles de codage, de nommage des variables et méthodes, etc. Sonar est un outil qui permet d'évaluer rapidement et clairement la qualité des projets Maven2, mais aussi
d'autres types de projets, moyennant une "Mavenisation" assez simple. Il s'appuie sur des outils comme Checkstyle, PMD et Cobertura et offre un reporting web très intuitif pour synthétiser les résultats de ces différents outils et guider l'utilisateur sur la voie de la qualité.


Applying Creational Design Patterns in Java
Design patterns, made famous by the "gang of four" (GOF) [9], as they are fondly called (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), are a collection of proven steps to be followed for a particular type of problem in software scenario. Java Design patterns provide a time tested solution which can be applied to a set of problems (the problems will have a common set of characteristics) to come to a solution. Obviously, the solution should be optimal in terms of execution.
Among the different categories of Java Design Patterns available, this article will focus on "Creational Design Patterns" [10], which focus on the creation of objects in Java from a class or group of classes. The patterns present under the umbrella of Creational Design Patterns basically define:

• How the Objects will be instantiated
• How many Objects will be instantiated
• At what point the Objects will be instantiated

VisualVM 1.2 Adds Powerful New Performance and Memory Profiler
VisualVM 1.2 has just been released and is available for download at
https://visualvm.dev.java.net [1]! After eight months of development, this release introduces many new features and improvements, including a new sampling profiler (read further for details), redesigned charts, unmatched jstatd support and customizable proxy settings.


JUnit: A Little Beyond @Test, @Before, @After
Most people I see using JUnit are limiting themselves to the very basic features, that is, indicating tests with @Test and maybe @Before and @After. Hey, I myself didn't do much more than that up to a couple of weeks ago. This is just a syntactical update to Java 5, but later releases of JUnit can do much more.


Mixing Heavyweight and Lightweight Components
Historically, in the Java language, mixing heavyweight and lightweight components in the same container has been problematic. However, as of the JDK 6 Update 12 and JDK 7 build 19 releases, mixing heavyweight and lightweight components is easy to accomplish. This article explains some details you might need to know.
Contents:

• A Bit of History
• Component Mixing Just Works
• Requirements
• Limitations
• Demo