C'est lors de la très intéressante conférence Eclipse Day Paris 2010 que LeMagIt a réalisé un long interview de Mike Milinkovitch, le directeur de la fondation Eclipse. Plusieurs sujets sont abordés mais nous retiendrons cette phrase: "la plupart des outils de développements d'ici 10 ans s'exécuteront dans le navigateur" ...

A noter que Mike explique aussi dans un post récent pourquoi la fondation eclipse votera oui aux JSR récemment soumises au JCP par Oracle.

Suite à l'annonce surprise d'IBM de lâcher Apache Harmony pour soutenir OpenJDK, les projections vont bon train pour savoir quels seront les résultats des votes sur les futures JSR pour JavaSE 7 et JavaSE 8.

La fondation Eclipse a jugé bon de communiquer ses intentions de vote : 'Oui pour JavaSE 7' et 'Non pour JavaSE 8'. Pour JavaSE 7, l'argument utilisé est la nécessité de sortir JavaSE de l'ornière rapidement, pour JavaSE 8 c'est naturellement les travaux sur la modularité qui posent problème avec le conflit entre Jigsaw et OSGi.

Au final Oracle aura fait peu d'annonces concrètes lors de JavaOne. Concernant Eclipse, le communiqué de presse d'Oracle évoque uniquement la création d'un nouveau projet nommé Sapphire.

Ce projet est intéressant pour les développeurs de plugins eclipse car il devrait permettre de créer rapidement des interfaces graphiques présentables. Le communiqué de presse présente ce projet comme une marque forte d'engagement d'Oracle sur Eclipse, la réalité est plus nuancée : un projet utile mais pas fondamentale pour la fondation Eclipse, une annonce pas vraiment nouvelle car la demande de création du projet date de juin et des ressources limitées (2 committers). L'impression finale est qu'Oracle a fait les fonds de tiroirs pour avoir au moins un petit mot gentil à dire à la fondation Eclipse lors de JavaOne :-)

Quest software propose une version béta de 'Toad Extension for Eclipse', le but est d'intégrer directement à Eclipse une partie des fonctionnalités de Toad pour Oracle.

Oracle annonce la disponibilité d'une nouvelle version de 'Oracle Entreprise pack for Eclipse', son environnement de développement basé sur Eclipse. Cette version est basée sur Eclipse 3.6.

Comme annoncé, Oracle a publié un nouveau build de la JVM 6u21 (la version exacte du build est maintenant '1.6.0_21-b07'). Le post 'The Eclipse/Java 6u21 Blame Game' explique pourquoi Eclipse s'appuie sur le nom de la JVM.

Bonne nouvelle pour la communauté Eclipse et surtout pour les développeurs d'applications ou de produits basés sur Eclipse : Oracle a proposé de remédier au problème de plantage d'Eclipse 3.x lancé avec la JVM Sun en version 6u21 (uniquement sur Windows). La modification minime qui affectait Eclipse va être annulée, le correctif devrait être rapidement disponible via un nouveau build de Java SE 6u21 ou bien via la mise à disposition de la version 6u22.

En attendant, il est conseillé de ne pas utiliser la version 6u21, fort heureusement cette version ne semble pas avoir donné lieu à mise à jour automatique, l'impact du problème devrait donc rester assez réduit.

La semaine dernière Oracle a publié une mise à jour de JavaSE. Cette version nommée 'Java SE 6 update 21' ou plus sommairement '6u21', inclus une modification apparemment anecdotique : le nom de fournisseur renvoyé par la JVM n'est plus 'Sun' mais 'Oracle'.
Malheureusement Eclipse utilise depuis longtemps cette information pour fixer un des paramètres mémoire de la JVM Sun ('-XX:MaxPermSize').

Concrètement, si vous lancer Eclipse avec la version 6u21, le paramètre mémoire MaxPermSize ne sera pas correctement dimensionné et il y a de fortes chances qu'Eclipse plante assez rapidement.

La solution est simple, il faut ajouter la ligne suivante à la fin du fichier eclipse.ini :
-XX:MaxPermSize=256m

Le vrai problème est que sauf a avoir eu connaissance de ce problème, beaucoup d'utilisateurs auront du mal à en identifier la cause, il est donc important de relayer cette information. A noter qu'il est probable que la fondation Eclipse décide de livrer de nouveaux builds d'Eclipse 3.6 et d'Helios intégrant le correctif, mais le problème restera entier pour les anciennes versions.

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.

Oracle propose une video de présentation de la nouvelle version de son IDE basé sur Eclipse. Il se dégage de cette présentation qu'Oracle semble réellement déterminé à appliquer la stratégie annoncée côté IDE : proposer et maintenir 3 solutions gratuites, JDeveloper, Eclipse Oracle Entreprise Pack et NetBeans. La justification étant de laisser le choix aux développeurs. Cette stratégie est étonnante de la part d'Oracle, sera-t-elle pérenne ? En tout cas, pour l'instant, elle est crédibilisée par des éléments concrets.

L'actualité d'OSGi en entreprise est dense en cette fin d'année : après l'annonce de la création du projet Gemini par Oracle et Spring Source, c'est IBM qui propose son implémentation de la spécification 'OSGi Entreprise'.
Cette implémentation, nommée 'OSGi Applications Open Alpha', permet d'ajouter à un serveur WebSphere 7 les fonctionnalités de déploiement et d'exécution de modules OSGi.

Avec le soutien d'Oracle, d'IBM, des communautés Spring, Glassfish et JOnAS, il ne fait maintenant plus de doute que l'utilisation d'OSGi côté serveur va se généraliser.

SpringSource et Oracle ont publié la proposition de création du projet 'Enterprise Modules Project', nom de code 'Gemini'. Ce projet a pour but de faire le lien entre OSGi et les technologies Java serveur. Des sous-projets seront créés pour implémenter les spécifications publiées par 'l'OSGi Enterprise Expert Group'.

Ludovic Champenois annonce sur son blog la version 1.0 du 'GlassFish Tools Bundle For Eclipse'. Cette approche nous semble intéressante : les équipes de développement sont rarement amenées à changer de serveur d'applications, leur proposer un outillage packagé et pré-configuré est plus simple que de partir de la distribution trop générique qu'est Eclipse IDE for Java EE developers. Félicitations à l'équipe de Sun et souhaitons que Glassfish trouve sa place chez Oracle.

Le tutorial 'JPA Hibernate with Oracle on Eclipse' liste les étapes de configuration pour faire fonctionner un exemple JPA dans Eclipse en utilisant Hibernate et Oracle.

Comme annoncé début juillet, Oracle rend disponible gratuitement l'environnement de développement de BEA basé sur Eclipse. Le nom officiel est 'Oracle Workshop for WebLogic 10.3'. A noter que cet outillage n'est pas spécifique au serveur WebLogic puisqu'il intégre des modules pour Tomcat, Jetty, JBoss et WebSphere.

Pour en savoir plus :
Un résumé de l'annonce d'Oracle
La page d'Oracle Workshop for WebLogic 10g R3
Télécharger 'Oracle Workshop for WebLogic 10g R3'

Un peu plus d'un an après l'annonce de la mise en open-source de TopLink par Oracle, le projet EclipseLink vient de livrer sa première version.

A noter que lors de la clarification récente de sa stratégie, Oracle a annoncé que WebLogic devenait le serveur Java EE à la base de son offre Java, avec toutefois une modification non négligeable: le remplacement de l'implémentation JPA de Weblogic par EclipseLink.

Certains continuent à penser qu'EclipseLink est une version allégée de Toplink, cette citation du responsable du projet EclipseLink lève toute ambiguité: "All of the persistence functionality of Oracle TopLink is included in EclipseLink. All of the TopLink development team now exclusively develops new functionality in EclipseLink" (extrait de 'My Thoughts on EclipseLink 1.0')

Pour en savoir plus :
L'annonce de la disponibilité de la version 1.0
L'article: 'Introducing EclipseLink'
La page de téléchagement d'EclipseLink

Le projet EclipseLink, créé suite à la mise en open-source de TopLink par Oracle, a été choisi pour être l'implémentation de référence de la spécification JPA 2.0 (JSR 317). Dans la pratique cela signifie notamment son intégration dans Glassfish V3.

Pour en savoir plus :
'Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference Implementation'
La page de la JSR 317 (JPA 2.0)

Un représentant de Microsoft a laissé entendre qu'une annonce de collaboration sera faite cette année lors de la conférence EclipseCon 2008 (17 au 20 mars). D'ici là les supputations devraient aller bon train sur le(s) projet(s) de la fondation Eclipse concerné(s) par cette annonce.

Rappelons que la conférence 2007 avait été notamment marquée par l'annonce d'Oracle sur la mise en open-source totale de TopLink (création du projet EclipseLink).

Pour en savoir plus :
'Microsoft cited for open efforts, eyes Eclipse'

Le projet EclipseLink (version open-source de TopLink) devrait prochainement livrer sa version 1.0. Les équipes d'Oracle ont commencé à publier la documentation complète.

Pour en savoir plus :
'EclipseLink User's guide'
Le document : 'EclipseLink Architecture'

Le projet EclipseLink propose une implémentation complète de JPA (Java Persistence API). Ce projet, animé par Oracle, a été créé suite à la mise en open-source de TopLink. Le premier build est disponible.

Pour en savoir plus :
Téléchargement du build 1.0M1
La page des exemples
La page du projet EclipseLink