Eclipse MAT (Memory Analyzer) est un outil très complet pour analyser les problèmes mémoire. L'article 'Détecter et corriger les fuites mémoire java', en français, propose une bonne introduction à l'utilisation de MAT.

Eclipse 3.6 RC1 est disponible, c'est le premier build d'une série qui nous amènera à la sortie officielle d'Eclipse 3.6 le 23 juin (le planning de finalisation d'Eclipse 3.6)

IBM propose une preview (version 0.5) de son futur outillage dédié au devéloppement d'applications OSGi.

Dans l'interview 'Apache Aries: Marrying OSGi with Java EE', l'un des contributeurs du projet Apache Aries fait le point sur l'avancement de ce projet qui a pour but de fournir une plate-forme basée sur la spécification OSGi Enterprise.

La fondation Eclipse et Google annonce la création du site Eclipse Labs. Il s'agit d'une plateforme d'hébergement pour des projets, non-officiels, tournant autour du monde Eclipse.

Angelo Zerr vient de publier la 19ème et dernière partie de son tutorial 'Conception d'un client Eclipse RCP et serveur OSGi avec Spring DM'. Le niveau de détail est impressionnant et l'approche progressive devrait répondre à de nombreuses questions. Le plan complet du tutorial est consultable sur cette page.

Le septième build stable d'Eclipse 3.6 est disponible : la page de téléchargement d'Eclipse 3.6M7, la liste des nouveautés d'Eclipse 3.6M7.

Alors qu'elle utilisait pour l'instant le terme 'e4 1.0' pour désigner la future version d'Eclipse, la fondation Eclipse a choisi de simplifier les choses en adoptant la désignation officielle 'Eclipse 4.0'. Une nouvelle version du document de travail d'Eclipse 4.0 est disponible.

Bien que cette annonce est bonne nouvelle, elle soulève deux interrogations :

• comment éviter le risque de confusion sachant qu'Eclipse 3.6 et 4.0 devront cohabiter (Eclipse 3.6 arrivera en juin et Eclipse 4.0 en juillet) ?
• les deux versions vont-elles continuer à évoluer en parallèle (comme prévu jusqu'à maintenant) ou bien la version 4.0 devient elle la base des futures évolutions ? (Pas de version 3.7 ?)

Le cinquième build d'e4 1.0 est disponible, encore quelques mois avant la version finale. Rappelons qu'e4 (Eclipse 4) ne remplacera pas Eclipse 3.x qui continue à évoluer (la version 3.6 sortira en juin et il y aura une 3.7 en 2011). e4 est une refonte du coeur d'Eclipse qui, dans un premier temps, intéressera essentiellement les développeurs d'applications Eclipse RCP. La présentation 'Eclipse e4 Overview' donne un très bon aperçu des évolutions proposées par e4.

Sonatype, la société derrière Maven, propose que Tycho devienne un projet officiel de la fondation Eclipse. Tycho rend l'utilisation de Maven de façon quasi-transparente pour la construction des applications OSGi (et donc Eclipse RCP).

Le support de la présentation 'OSGi & Java EE in GlassFish' est disponible . Il donne un bon aperçu de la façon dont Glassfish permet aux développeurs d'exploiter le meilleur des deux mondes (JavaEE et OSGi).

Non, je n'ai pas fait une erreur de frappe en tapant le titre de cette news. Qwylt est un projet, plus ou moins interne, lancé par Oracle début 2009. Ce projet correspond à ce qui a été évoqué lors d'une présentation animée par deux responsables importants d'Oracle (notamment le responsable de la stratégie Java).

Le but de Qwylt est de proposer une API permettant d'interargir avec des systèmes de gestion de modules. Le peu d'informations données actuellement laissent supposer que Qwylt pourrait être intégré au JDK 7. Qwylt ne remplace pas OSGi ou tout autre système de module, son but est de créer un niveau d'abstraction masquant le système de gestion de modules utilisé. La première justification à cette approche est de trouver un moyen permettant d'utiliser à la fois OSGi et Jigsaw (le système de modules interne au JDK 7). Espérons qu'Oracle donnera plus d'informations prochainement.

Cette semaine se tenait la conférence EclipseCon 2010. Suivez ce lien pour obtenir la liste des présentations dont le support est disponible.

La spécification OSGi Enterprise vient d'être publiée en version finale. Cette spécification marque une étape importante pour OSGi. Elle décrit notamment comment OSGi peut s'intégrer dans un contexte JavaEE. Jusqu'à maintenant, OSGi s'est développée en parallèle du monde JavaEE, d'où certaines difficultés pour faire cohabiter les deux mondes. Avec les projets Eclipse Virgo, Eclipse Gemini et Apache Aries, des implémentations d'une bonne partie de cette spécification sont dès aujourd'hui disponibles. Parions qu'avec cette spécification, OSGi va prendre une nouvelle dimension.

Cette page donne un premier aperçu synthétique du contenu de la spécification,

Dans l'article 'OSGi, and How It Got That Way', Neil Bartlett choisit d'expliquer les concepts d'OSGi d'une façon originale et intéressante. Il se replace dans un contexte où OSGi n'existerait et il déroule un à un les besoins d'un système modulaire en Java et les solutions qui lui semblent les plus logiques. Bien évidemment, il arrive à la fin à la recréation d'OSGi.
Sur le fond il y a plusieurs remarques intéressantes, notamment le fait de bien préciser que l'aspect dynamique d'OSGi n'est pas un point principal mais une conséquence offerte pas des choix vraiment fondamentaux (un classloader par module et un conteneur donnant une existence aux modules lors de l'exécution).

Une bonne démo qui permet de visualiser les possibilités offertes par Eclipse RAP.

Le sixième build stable d'Eclipse 3.6 est disponible : la page de téléchargement d'Eclipse 3.6M6, la liste des nouveautés d'Eclipse 3.6M6.

Un article en français sur les choix possibles pour réduire les dépendances cycliques entre modules OSGi.

Dans l'interview 'Using OSGi and Equinox effectively', l'auteur du livre 'OSGi and Equinox' répond à plusieurs questions intéressantes. Parmi ses conseils sur l'utilisation d'OSGi, il y en a deux qui ne sont pas assez souvent exposés :

• limiter au maximum les appels aux API propres à OSGi (en privilégiant une approche déclarative).
• éviter d'utiliser les BundleActivator. Leur utilisation doit être exceptionnelle. Effectuer systématiquement des tâches d'initialisation dans les BundleActivator peut avoir un impact fort sur les temps de démarrage.

Le second tour de vote pour le nouveau logo d'Eclipse est accessible sur cette page. Le premier tour s'est soldé sur un beau raté : les deux logos ayant récoltés le plus de suffrages étaient trop différents de l'actuel au goût du responsable marketing de la fondation (impact trop coûteux du changement de logo). Comme c'est parti, il y a de grandes chances que le logo actuel soit conservé et que la refonte se fasse plus doucement après la sortie des versions 3.6 et e4 1.0.