La semaine dernière, la fondation Eclipse a annoncé la sortie d'Eclipse Juno M5, une étape importante de la sortie de cette été de la suite Eclipse. Cette version apporte de nouvelles fonctionnalités, telle que la détection inter-méthode des potentielles Null Pointer dues aux déférencements et la détection des fuites de ressources (en Java 7, un try-with-resources peut fixer le problème, en Java 6 la gestion standard du try/catch suffit)
Pour la première fois, la sortie combinée d'Eclipse sera basée sur E4. Ceci représente une ré-écriture significative de l'infrastructure de l'interface utilisateur d'Eclipse utilisant les modèles déclaratives EMF au lieu de code représentant l'interface utilisateur. Le modèle peut alors être introspecté et modifié en cours d'exécution, provoquant des modifications qui sont rendues immédiatement dans la fenêtre, et peut aussi fournir une persistance automatique de la sauvegarde de l'état d'une vue en cas de besoin.
L'avantage principal de la modélisation déclarative de l'interface utilisateur est que comme pour le HTML, il est possible de séparer l'organisation de sa présentation. Ceci permet l'utilisation du CSS pour styliser l'interface utilisateur, et de se préoccuper séparément de la gestion manuelle des composants dans du code et ainsi éviter des fuites mémoires dues aux ressources non libérées.
Une autre amélioration de E4 est l'utilisation de l'injection de dépendances pour accéder aux services requis. Précédemment, des accesseurs statiques étaient utilisés pour obtenir la plateforme de services qui était fréquemment utilisée (comme le SelectionService, qui fournit les informations lorsque la sélection change entre différentes vues). Ces services ont été disponibles dès le lancement initial de la plateforme Eclipse mais malgré la transition vers une architecture OSGI pour Eclipse 3.0, les services n'étaient pas exposés en tant que services OSGI. Avec E4, ces services de la plateforme sont maintenant disponibles en tant que services OSGI et peuvent être consommés à la fois par Eclipse et les clients OSGI.
Pour faciliter l'obtention des services qui sont typiquement des singletons (Workbench Selection Service, Logging Service, etc...), des plugins Eclipse peuvent désormais déclarer un point d'injection pour les services demandés. Quand E4 se met en marche et charge un plugin, il va déterminer quels services sont requis et il va les lier en se basant sur la plateforme d'exécution. Ceci est surement familier à ceux qui ont utilisé Spring, plutôt que d'avoir besoin de mettre en place un contexte d'application, cela nous vient gratuitement lorsqu'on se base sur le contenu de la plateforme. L'injection est faite avec l'annotation standard javax.inject.Inject, qui peut être définie sur un appel de base d'un champ ou d'une méthode.
Puisque le mécanisme de recherche de services a changé significativement entre l'ancien Eclipse 3 et Eclipse 4, une couche de compatibilité ascendante permet de fournir les mêmes APIs qui sont attendus par les plugins basés sur de anciens environnements. A noter que ces APIs remplacent complètement leur ancienne implémentation et qu'elle peuvent contenir des bugs et des fonctionnalités non présentes dans les versions précédentes.
La transition vers E4 a été faite de manière graduelle. Tout d'abord lancé comme SDK 4.0 après la version d'Helios 3.6, s'en suit une version SDK 4.1 destiné aux développeurs d'Eclipse après la version 3.7 Indigo. Pour la sortie de Juno, l'objectif sera que les utilisateurs migrent vers la plateforme 4.2 bien qu'il y aura une sortie finale 3.8 de disponible.
Cependant, le projet Eclipse a déjà laissé des traces à travers les années. Tout d'abord lancé par IBM, la plateforme Eclipse a toujours été lourdement chargée par les employés d'IBM. Le tableau de bord liste de nombreux membres et ex-membres d'IBM et une petite proportion de contributeurs externes. Dans un e-mail destiné aux équipes projets, Mike Wilson (Comité de la gestion des projets Eclipse) a souligné qu'il ne restait plus que 3 développeurs sur le projet Plateforme Interface Utilisateur. Ce qui a mené à des inquiétudes de plus en plus importantes sur le fait que Juno soit prêt à temps; et avec de tels problèmes, Mike souligna qu'un retard serait "catastrophique pour notre communauté".
Certains peuvent soutenir qu'il serait mieux de simplement livrer la version 3.8 dans Juno et passer à une 4.x aux sorties suivantes. Honnêtement, je crois que ceci serait catastrophique pour notre communauté. La sortie simultanée de Juno est en train d'être à la base d'une offre pour le premier support très long terme d'Eclipse. En plus de la maturité globale d'Eclipse et les besoins de nombreuses et grandes organisations qui y participent, je vois la sortie de Juno comme extrêmement importante. Si nous ne sommes pas capable de livrer la 4.2 dans Juno, cela signifierait qu'un bon nombre de la communauté ne serait pas capable de profiter des nouvelles fonctionnalités qu'elle fournit mais plus important, ils produiraient sur une base de code que nous savons devoir être bientôt remplacée et après tout c'était d'ailleurs dans ce but que nous voulions livrer la 4.x. Cela signifierait aussi qu'il ne sera non plus possible d'adapter la plateforme(sur laquelle nous construisons) aux changements des besoins des clients lourds et modernes. Et ceci, plus que tout autre point qui me vienne à l'esprit, pourrait dénigrer le futur d'Eclipse dans le monde du client lourd.
Il continue en faisant savoir qu'il a bien entendu les inquiétudes concernant la sponsorisation par une entreprise unique du projet Eclipse, du moins en terme de contributeurs :
Finalement, ce qui est clair pour moi dans tout ceci est que l'équipe de l'interface utilisateur de la plateforme Eclipse, et en fait tout le projet Eclipse, a besoin dès maintenant de contributeurs externes à IBM. Et par ceci, je veux dire des contributeurs actifs et "travaillant sur le SDK pour le bien de la communauté Eclipse en général." Tous ces arguments sur le manque de diversité sur le projet Eclipse sont en train de nous porter préjudice : il est clair que maintenant les contributeurs restants d'Eclipse IBM ne sont pas assez nombreux pour supporter le SDK entier.
Wayne Beaton, évangéliste de la fondation Eclipse, croit que la neutralité d'un distributeur en projet open source est non seulement essentielle mais fait surtout parti des règlements d'Eclipse.
La technologie Eclipse est une plateforme de développement neutre et libre fournissant des frameworks ainsi que des outils extensibles ("plateforme Eclipse").
Finalement, la fondation Eclipse a aussi décidé que la suite Eclipse de l'année prochaine se nommera Eclipse Kepler. Bien qu'il eut déjà une proposition de projet aussi nommée Kepler, le projet n'a jamais convaincu et fut archivé peu après avoir été proposé.
Nous attendons maintenant avec impatience Eclipse Kepler, bâtit sur Eclipse 4.3, qui arrivera à l'été 2013.