Le weblogue de SeB

Ce n’est pas nouveau, Geronimo est certifié Java EE 5 depuis la version 2.0. Et il y a un peu moins d’un mois, la version 2.1 est sortie.

Cette nouvelle version apporte son lot d’améliorations, corrections et de nouvelles fonctionnalités dont :

• Custom Server Assemblies : pour simplifier la construction d’un serveur sur-mesure
• Flexible Administration Console : une console d’administration du serveur
• GShell : un environnement d’exécution de ligne de commande supportant Groovy
• WADI Clustering : permet de monter aussi bien des clusters de Jetty ou Tomcat
• Monitoring support : accessible via la console d’administration, il permet de superviser l’état de l’ensemble des serveurs

Pour plus d’informations, vous pouvez consulter l’annonce officielle de publication de Geronimo 2.1.

Comme toujours, ce serveur d’applications open source est disponible en libre téléchargement sur la page du projet.

Lors de l’étape de compilation, le Java permet de lever les warnings sur des portions de code qui sont corrects d’un point de vue syntaxique, mais qui peuvent poser des problèmes lors de leur exécution.

Le warning le plus courant est sûrement le suivant :

Type safety: Unchecked cast from Object to Collection<String>

Cependant, dans certains cas, le code est correct et ne posera pas de problème à l’exécution. Depuis Java 5.0, il est possible d’indiquer au compilateur, via les annotations, d’ignorer certains warnings sur des blocs de code donnés. Ceci est possible grâce l’annotation @SuppressWarnings.

Par exemple, dans le cas précédent et dans le cas moins évident présenté ci-dessous :

List is a raw type. References to generic type List<E> should be parameterized

Il faut utiliser, l’annotation de la façon suivante :

@SuppressWarnings("unchecked")

L’annotation @SuppressWarnings accepte un nombre important de paramètres. Damien Viel propose une liste des valeurs possibles.

Attention ! Cette annotation doit être utilisée à bon escient. Il est recommandé de se demander pourquoi le Java lève un warning à cet endroit et s’il peut réellement être ignoré…

Pour rappel, les EJB3 sont le résultat du mariage entre les EJB2 et Hibernate et XDoclet Hibernate Annotation.

Lorsque les développeurs travaillent avec Hibernate, ils prennent vite l’habitude d’utiliser le HQL pour les requêtes statiques et l’API Criteria pour les requêtes dynamiques^[1]. Cependant, le passage d’Hibernate aux EJB3 Entities provoque quelques frustrations. En effet, mis à part le JPQL^[2] qui est l’équivalent du HQL chez Hibernate, il n’y a aucune API pour générer dynamiquement des requêtes sur les EJB3 Entities ! :-/

Faut-il attendre les EJBs 3.1 ou 4 ? Au moins de quelqu’un nous sorte de son châpeau une petite API Criteria pour les EJB3…

Notes

[1] Comme expliqué dans SQL natif, HQL ou API Criteria ?">le comparatif SQL, HQL et API Criteria.

[2] Pour lequel il existe un tutorial et une documentation de référence du language.

Il est courant d’utiliser une servlet qui permet de générer à la volée des fichiers PDF. Pour que ce flux de données retourné par la servlet soit reconnu en tant que fichier PDF par le navigateur, il est nécessaire de positionner quelques entêtes HTTP :

HttpServletResponse.setContentType("application/pdf");

HttpServletResponse.setHeader("Content-Disposition","attachment; filename=mydocument.pdf");

Cette solution fonctionne très bien avec n’importe quel navigateur sauf avec le couple IE6/Acrobat. Dans ce cas, Acrobat s’ouvre mais affiche le message d’erreur ci-dessous :

une erreur est survenue lors de l’ouverture de ce document

Pour résoudre ce problème, il faut ajouter la ligne suivante dans le code de la servlet qui génère le flux de données du fichier PDF :

 HttpServletResponse.setHeader("Cache-Control","private, must-revalidate");

Maintenant le plugin Acrobat est capable d’ouvrir les documents PDF généré par la servlet. Notez que cette astuce n’est pas seulement valable pour le Java. Vous pouvez l’utiliser pour n’importe quel language puisque que le problème se situe au niveau du protocole HTTP.

A vos PDF !

Le terme mustang est souvent utilisé aux Etats-Unis pour désigner des produits de haute performance. Le nom de code choisi pour Java 6 annoncait les enjeux de la version. Java 6 est sorti aujourd’hui, et il semble bien que le défi soit relevé !

En effet, d’après Alexis^[1], Java 6 offre des performances d’environ 30% supérieures à Java 5. Bien entendu, ce n’est pas la seule nouveauté de la toute fraiche mouture de Java. adiGuba ayant déja fait le travail, je vous redirige vers son article expliquant de façon très détaillée les nouveautés de Java 6 telles que :

• support de language de script
• mise à disposition de l’API de compilation
• amélioration de l’API de traitement des annotations^[2]
• ajout de nouvelles annotations
• nouveau format des classes compilées
• passage à JDBC 4.0^[3]
• intégration des Web Services
• pleins d’autres choses…

Si vous cherchez plus de lecture sur le sujet, je ne saurais trop que vous conseillez le Java 6 - top ten.

Notes

[1] Qui semble bien éreinté par cette publication.

[2] Apparue avec Java 5.

[3] Dont je vous ai déja parlé JDBC - Les nouveautés de JDBC 4">ici et JDBC - les améliorations de JDBC 4 dans Java SE 6">là.

Quel meilleur sujet que le passage sous license Open Source de Java pour reprendre l’activité de ce weblogue ?

Effectivement, Java passe sous la license GPL. A cette occassion Developpez.com retrace l’historique de cette affaire.

Mis à part IBM, tout le monde se fécilite de ce passage de Java en license Open Source. IBM aurait préféré l’utilisation de la license Apache mais Sun a retenu la GPL. La license Apache était souhaitée pour une hypothétique fusion avec le projet Harmony.

Cet événement est très important pour les utilisateurs et pour les développeurs. Effectivement, on peut espérer une meilleure réactivité quant à la correction des anomalies. Le point positif c’est que le projet Classpath n’est pas distribué sous la GPL. Ainsi, les produits écrit en Java ne seront pas obligés d’être distribués sous la même license. Notez cependant que la marque Java est toujours la propriété de Sun.

L’intégration douloureuse de Java dans les distributions GNU/Linux m’empêchait d’écrire des applications de bureau en Java. Le problème était d’autant plus génant lorsque l’on souhaitait être intégré dans la distribution GNU/Debian^[1]. Ce problème devrait être résolu.

Et si l’on se dirigait vers GNU/Linux Java inside ?

Si vous souhaitez en savoir un peu plus sur les conséquences de ce changement de license, n’hésitez pas à lire l’interview Guillaume Boget sur ce qui va changer.

Notes

[1] Même si l’installation de la JVM sous Debian est possible.

J’ai plutôt l’habitude de parler d’Eclipse. Cependant, aujourd’hui c’est l’IDE Netbeans qui est à l’affiche.

Effectivement, le projet JOnbAS est un nouveau module pour Netbeans 5.5 qui ajoute le support de JOnAS. Il permet :

• Le démarrage et l’arrêt du serveur.
• Le débuguage des JSP et du Java.
• La génération des descripteurs de déploiement spécifiques.
• Le déploiement des EAR, EJB et WAR.
• L’exploration des modules déployés.

Ce module est rapide à installer et vraiment très simple à utiliser.

Ce travail est le résultat des efforts réalisés par Stepan Herolds. Tout retour d’expérience, rapport d’anomalie ou suggestion sont les bienvenus.

Jusqu’à présent la version version de Struts était la 1.2.9. La nouvelle version est la 1.3.5. Cette version correspond à la branche de développement de Struts 1.3^[1].

Il existe d’importantes différences entre Struts 1.2 et Struts 1.3 :

• Le projet est découpé en plusieurs JARs séparés correspondant à chaque sous-projet :
  • Core
  • Applications
  • EL
  • Extras
  • Faces
  • Scripting
  • Taglib
  • Tiles
• Le projet est géré avec Maven 2.
• Le RequestProcessor reprend le modèle de conception CoR et est configurable via un fichier XML avec Commons Chain.
• Migration vers J2SE 1.4, Servlet 1.3 et JSP 1.2.
• Intégration de Commons Validator 1.3.0.
• Gestion des boutons annuler.
• Support de l’héritage dans les fichiers de configurations.
• Détermination des URLs de soumission des formulaires avec les postback actions.
• Diverses améliorations sur la configuration.

L’annonce de la précédente version beta de Struts 1.3.5 donne plus de détails sur les nouveautés depuis Struts 1.2. L’annonce de la version officielle de Struts 1.3.5 présente également une grande partie des nouveautés.

Il ne vous reste plus qu’à migrer de Struts 1.2 vers 1.3 !

Et pour ceux qui souhaitent en savoir un peu plus sur Struts pour l’année 2006, allez lire de ce pas Struts 2006: An Embarrassment of Riches si vous ne l’avez pas encore fait.

Notes

[1] Annoncé en décembre 2005.

Vous utilisez la JSTL et les EL. Vous avez banni les scriplets de vos pages JSP. Mais comment faire référence à une constante Java dans vos pages JSP ?

Jakarta Taglibs propose les unstandar tags. Parmi ces tags, il y a le tag <un:useConstants/>. Ce tag permet d’enregistrer dans un context les constantes d’une classe Java sous la forme d’une Map.

Puisqu’un exemple est plus efficace qu’un long discours. Voici une mise en application de l’utilisation de constante dans une page JSP :

Le code Java :

package com.company.project.MyConstants; public class MyConstants {
	public static final String PROJECT = "My Project";
	public static final String VERSION = "1.0.0";
}

La page JSP :

<?xml version="1.0" encoding="UTF-8" ?>
<jsp:root
	xmlns:jsp="http://java.sun.com/JSP/Page"
	xmlns:un="http://jakarta.apache.org/taglibs/unstandard-1.0"
	xmlns="http://www.w3.org/1999/xhtml"
	version="2.0">
<jsp:directive.page
	language="java"
	contentType="text/html; charset=UTF-8"
	pageEncoding="UTF-8" />
<jsp:output
	omit-xml-declaration="false"
	doctype-root-element="html"
	doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
	doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"/>
<html>
	<head>
		<title>Use of Java constants</title>
	</head>
	<body>
		<un:useConstants var="myconstants" className="com.company.project.MyConstants" />
		Welcome to ${myconstants.PROJECT} v${myconstants.VERSION} !
	</body>
</html>
</jps:root>

Comme vous pouvez le constater, ce tag facilite grandement la tâche et vous évitera quelques noeuds au cerveau.

Mysaifu JVM continue d’évoluer tranquillement. Ainsi, c’est Mysaifu 0.3.0 qui vient d’être publiée.

Les nouveautés de cette dernière version concernent essentiellement l’organisation du code source et l’environnement de développement. Néanmoins, il est dès à présent possible de modifier le classpath et le répertoire courant par défaut via la base de registre.

Il faut noter que depuis JVM - écoute et parle">la version 0.2.2^[1] cette JVM a intégré la dernière version de GNU Classpath^[2]. Et surtout, elle supporte la plateforme MS Windows Mobile 5.0 ! A chaque nouvelle version, de nombreux bugs sont corrigés et le support de JNI est constament amélioré.

Notes

[1] Il y a tout de même eu huit versions !

[2] Passage de la version 0.91 à 0.92.