Deux écoles s'affrontent sur ces question de la simplification du développement et de l'amélioration de la productivité. La première est celle à laquelle vous faites allusion. Elle préconise l'assemblage visuel et entend masquer les complexités sous-jacentes. Mais ses principes ne fonctionnent pas très bien, car les technologies de développement des interfaces graphiques et l'environnement de développement ne peuvent pas complètement masquer les complexités du framework sous-jacent. C'est comme construire une maison en commençant par le toit alors que les fondations sont fragiles, pour ensuite passer une belle couche de peinture. De loin, cela paraît joli. Mais quand on entre, on s'aperçoit que les murs s'écroulent. C'est ce que proposent la plupart des fournisseurs de solutions de développement Java. La seconde école est celle de Microsoft. Là aussi, la peinture est magnifique. Mais, en plus, le framework ­ en l'occurrence .Net ­ est excellent dans sa philosophie. En fait, la démarche consiste à simplifier le framework. Les interfaces graphiques utilisateur n'en sont alors que plus simples à réaliser. C'est tout l'intérêt de l'approche de l'AOP [programmation orientée aspects ­ NDLR], que JBoss a adoptée. C'est une façon très simple ­ par des tags ­ d'introduire des fonctionnalités dans un objet. Ce que l'on inclut, ce sont des aspects comme la persistance ­ c'est-à-dire le stockage de l'objet dans une base de données ­, la gestion des transactions, ou encore la capacité de contrôler l'intégrité de l'état de l'objet en fonction de la transaction.

Du côté de BEA, il ne s'agit que d'une déclaration d'intention. En parallèle de ses implémentations commerciales, IBM est, en revanche, plus avancé dans ce domaine. Nous collaborons d'ailleurs avec ses équipes de chercheurs qui, techniquement, sont au même niveau que Jboss. A la différence près qu'elles n'ont pas encore implémenté leur technologie. Nous discutons avec Big Blue, notamment pour définir ce qui peut être standardisé. C'est-à-dire ce que l'on pourrait soumettre au JCP [Java Community Process ­ NDLR].

En nous proposant de rejoindre le JCP, Sun reconnaît publiquement que ce que nous faisons est très innovateur. Notre futur rôle dans cette organisation est celui d'un agitateur. Nous sommes persuadés que le futur du middleware réside dans l'AOP. Une technologie que nous implémentons dans JBoss 4, et que Microsoft implémente également. Nous promettons que notre ralliement au JCP contribuera à standardiser nos innovations.

Nous fournissons l'environnement de développement JBoss en tant que plug in pour Eclipse, mais nous ne sommes pas membre de cette communauté. Si Eclipse devient un point de rencontre, pourquoi ne pas la rejoindre. Mais, aujourd'hui, ce n'est pas le cas. Eclipse est surtout le symptôme de l'agacement de beaucoup de personnes vis-à-vis du leadership de Sun. Pour moi, le JCP est une bonne chose. Et je ne crois pas au futur de Java sans Sun. Néanmoins, il est vrai qu'il faut accélérer les innovations et l'évolution des spécifications de la plate-forme J2EE.

Java est, depuis sa création, un bon langage. Ce qui ne veut pas dire qu'il ne doit pas intégrer des évolutions comme l'AOP. Prendre en charge plusieurs langages, comme le fait la plate-forme .Net de Microsoft, n'est pas critique. Dans un projet de développement, l'important est d'avoir un bon langage, complété de bibliothèques et d'objets préfabriqués, c'est-à-dire la syntaxe et la grammaire avec lesquels on peut assembler des phrases limpides. Dans ce contexte, l'avantage de disposer de plusieurs langages est très minime, et l'intérêt de Java énorme. Je ne vois donc aucun bénéfice à distinguer le langage de la plate-forme.

La certification J2EE est surtout une marque contrôlée par Sun. Les développeurs qui utilisent notre produit savent que JBoss est très proche des standards. Pour preuve, ce qu'ils construisent sur JBoss marche sur les autres serveurs d'applications. Mais aujourd'hui, notre serveur d'applications est en passe d'entrer en phase de production dans de nombreuses entreprises. Dans ce contexte, les décideurs ont besoin de la certification J2EE. Il y a trois ans, nous avions demandé à Sun de passer l'examen de certification. Mais, à l'époque, nous ne pouvions payer la somme demandée. Sun ne nous ayant pas répondu, notre demande n'a pas abouti. Sun nous a récemment recontactés, à la suite de plusieurs de nos déclarations. Premièrement, après avoir annoncé que JBoss 4 se dirigeait vers la programmation orientée aspects, et que nous allions au-delà des spécifications J2EE. Deuxièmement, après avoir déclaré que ce que faisait Microsoft dans .Net avec C# était excellent. Après discussion, nous avons accepté, au début de l'été, les conditions contractuelles. Et notamment de verser, chaque année, plusieurs centaines de milliers de dollars pour la certification J2EE. Depuis, nous sommes toujours dans l'attente de pouvoir signer ce contrat dont nous avons accepté tous les termes.