BlogAtom

Via Matt, a comparison between Hibernate’s HQL and JDO’s OQL. I’m still not sure which one to use; I don’t like JDO too much and it doesn’t look like it’s gaining much popularity. Besides, I don’t think there is a convincing Open Source implementation of JDO. Another cool-sounding alternative I have to play with: Prevayler, as featured recently on Slashdot, is an in-memory transparent object-persistence layer. Their site is still slashdotted, apparently.

TheServerSide: P6Spy 1.0 Released. P6Spy is one of the most useful debugging tools I have found. Absolutely required if you need to debug or monitor database/JDBC problems while developing or in production.

This one really got me laughing Geek humor at its best!

They’re creating a hilarious new movie about Websphere developers. It’s called “Dude! Where’s My Classpath?”

To get it, first you must use WebSphere Application Server for a while. Then you must know about the movie. You could also ask Cedric.

WAS is well-known for its classloader weirdness. IBM has a whole article about it. TheServerSide has a good general article about J2EE classloading.

Plein de nouveaux outils de génération de code trouvés via ce post de James Strachan… Middlegen part d’un schéma SQL et peut générer des EJB, des Actions Struts et des classes JDO. Combiné avec Commons-SQL, cela pourrait donner un truc sympa qui permet de générer toute la structure d’une appli à partir de la description de son schéma de données. Mais je suis quand même dérangé par un truc: je pensais qu’il fallait commencer par concevoir le modèle objet, sans penser à la correspondance avec le modèle relationnel, puis générer le modèle relationnel de façon automatique… Or ces outils font exactement le contraire! UML2EJB, quant à lui, permet de générer des EJB à partir d’un modèle objet UML décrit en XMI. Cela paraît déjà plus logique. Maintenant il faudrait pouvoir en tirer le modèle de données…

Un article sur Maven dans JavaWorld. Maven est un projet Jakarta qui permet qui centraliser toutes les fonctions nécessaires à la gestion d’un projet Java: dépendances avec d’autres librairies, génération de la documentation, compilation, assemblage pour distribution, etc.

Maven est entre autres censé résoudre le problème de la gestion de dépendances: les projets Java Open Source ont tendance à avoir tellement de dépendances sur d’autres projets/librairies qu’il est impossible de tout recompiler; les projets sont simplement livrés avec des versions compilées de leurs dépendances. C’est un gros pas en arrière par rapport à des systèmes comme CPAN (pour Perl) ou RPM (pour Unix/Linux), qui permettent de reconstruire complètement des packages, en suivant leurs dépendances, et en téléchargeant les sources depuis un repository distribué. Il y a même des distributions Linux entièrement bâties sur ce concept.

Maven apporte une réponse malheureusement trop simpliste: ils stockent simplement les JAR dont dépend le projet sur le site de iBiblio. Les dépendances ne sont pas recompilées/réinstallées. Le repository n’est pas distribué (et s’il tombe en panne?). Et comment le repository est-il mis à jour avec les nouvelles versions?

Pour le reste, Maven semble un bon outil pour donner une structure standard à un projet Java. Il y a déjà pas mal de projets Jakarta qui l’utilisent, et c’est vrai qu’il est du coup plus facile de comprendre rapidement comment tout s’articule.

Un bon tableau comparatif des solutions de persistence d’objets Java sur Blogging Roller… Tous les critères « objectifs » sont réunis, mais il manquerait quelques informations pour pouvoir réellement faire un choix: performances, propreté du code, stabilité, etc. On remarque qu’il y a très peu de solutions qui implémentent l’API JDO. L’implémentation dans Jakarta OJB est certes très limitée, mais elle permet au moins de commencer à développer en « JDO-like », et donc de ne pas avoir à tout réécrire lors du passage en « vrai » JDO.

James Strachan mentionne qu’il ne recommanderait pas HSQLDB pour un usage sérieux. Je suis en train de convertir mon code pour utiliser une base embarquée à la place de MySQL, et j’ai donc fait un rapide comparatif des bases « embarquables » écrites en Java. J’avais déjà essayé HSQLDB donc il n’y avait plus rien à découvrir J’ai jeté un oeil à Axion mais les fonctionnalités m’ont paru vraiment limitées (pas de GROUP BY?? pas de LIKE??). J’ai finalement décidé d’essayer McKoi, qui paraît assez évoluée, stable, et en plus j’aime bien le nom ( »He’s dead, Jim!« ) J’ai déjà rencontré un petit problème de parsing SQL, que j’ai a priori résolu (finalement le temps passé à faire du Lex/Yacc à l’EPITA aura servir à quelque chose!)… Mon nouveau blocage est que OJB ne semble pas fonctionner très bien avec McKoi. Du debug en perspective

Dans la foulée de mon installation de RedHat, je me suis aussi installé Eclipse et j’ai vaguement tenté d’avancer un peu mon projet de Weblogger Java. Comme j’en avais assez de créer mes tables MySQL à la main, j’ai joué un peu avec le projet Jakarta Commons-SQL. C’est un ensemble de beans qui permet de décrire un schéma via des fichiers XML, puis de générer automatiquement les requêtes SQL permettant de créer les tables, et ce pour différents types de bases (MySQL, Oracle, etc.) Apparemment le même fichier XML source devrait permettre de créer les fichiers repository.xml pour OJB afin de gérer directement la persistence, ce qui serait bien pratique, mais je n’ai pas encore trouvé le système. Attention, si vous avez envie d’essayer, il y a très peu de doc et il est vivement recommandé d’installer Maven avant de tenter une compilation…

J’ai passé un petit moment à évaluer les différentes librairies Java de mapping objet/relationnel. J’ai commencé par utiliser Castor JDO, mais je n’ai pas été enthousiasmé: Castor ne respecte pas la norme JDO officielle et est assez contraignant à implémenter dans le cadre d’une application Web. Castor est certainement une bonne solution pour faire du mapping objet/XML, mais pas trop convaincant pour de l’objet/relationnel.

Je me suis donc mis à la recherche d’une implémentation gratuite de JDO. Libelis propose une version gratuite de son outil (LiDO Community Edition) limitée à InstantDB, MySQL et PostgreSQL, ce qui aurait été suffisant, mais j’ai finalement opté pour Jakarta OJB.

OJB est non seulement gratuit mais en plus Open Source. Leur implémentation JDO est encore partielle, mais elle est suffisante pour mes besoins. De plus OJB est un projet qui a de la bouteille, étant donné qu’ils ont déjà une implémentation ODMG complète.

Mike Cannon-Brookes linked to the French version of my small OSCache article last week. It looks like some people tried to read it using Babelfish, and unfortunately the result is quite confusing and somewhat ridiculous (somehow reminded me of Louis de Funès speaking English (more on this page)). So, here is an English version for your enjoyment!