Evil call to Character.getNumericValue(char)

In the Eclipse compiler, to detect a valid unicode, we call the method:
Character.getNumericValue(char) and we check that the returned value is between 0 and 15 to validate that only character between 0..F are allowed (see the JLS)
This was a mistake. Some characters can have a numeric value between 0 and 15 and they would not belong to the character between 0..F (including lowercase letters).
This bug report which shows why this was wrong was opened this week.

Here is a screenshot that shows the bogus code:

The fix is trivial, but it is surprising that this has never been found before. 10 years with that bug!


Enough for today.... back to work!

Kudos to Compuware!

Today I wanted to say "Thank you" to Compuware for organizing a very nice demo camp last night in Montréal. The demo camp lasted for more than 4 hours with a diverse and interesting set of demos. We heard about remote p2, shared install management, Eclipse at the Canadian Space Agency, new visualization of features dependencies, gdb debugging and tracing with CDT, Tycho, Vega demo and more....
I went there with Pascal from Sonatype and it was a really good event! Well organized, good beers, nice people! I am always puzzled to see how many people can show up in an Eclipse demo camp. The room was packed with around 50 people.

Kudos to Compuware! Hopefully this is not the last event in Montréal even if I cannot guarantee that I can come every time.

Workspace settings vs project settings

Today, I wanted to talk about the evilness of workspace settings. Workspace settings are used for a project when the project doesn't specify its own settings.
There are really good reasons why workspace settings should never be used for a Java project and in particular for a Plug-in project. To specify project specific settings, just open the project Properties, the select the options you want to be specific to your project and select "Enable project specific settings". For example, for compiler settings, it would look like this:

Let's take a Plug-in project that is using a EE (Execution Environment) 1.4 and therefore it doesn't use generics. Now you don't set project specific settings for this project, which means that once this project is checked out inside your workspace it will be compiled using the workspace settings. If you are using a 1.6 VM to run your workspace, the default compiler settings for this workspace will be set to 1.6.
So your project might end up with many warnings once checked out that are unexpected: raw type warnings, unchecked type warnings,...
When you set up a Plug-in project, you should also set up all compiler settings to be specific to this project. You should set the libraries on the classpath to explicitly point to your EE.
You must make sure that compiler warnings are set up so that your project compiles without any warnings or at least a limited number of warnings. Warnings should always be under control. You either don't care about some warnings and in this case they should be disabled, or you do care about them and then they should be fixed.
Setting project specific settings means that any user that checks out your project will get consistent compilation regardless the workspace settings they are using.
This also means that any Plug-in project should always set an EE. Without any EE explicilty specified, the default VM libraries are set up on the project's classpath and this means that the classpath depends on the workspace settings.
This being said, if you do set an EE for your project, you should also make sure it is using API tooling even if you don't really provide APIs in your project.
You can at least benefit from the detection of invalid references to the EE you are using. API tooling has a disabled option (by default) that you should enable for your project to detect all invalid usage of types, fields and methods that are not defined for the EE specified for the project. See Project's Properties>Plug-in Development>API Errors/Warnings>API Use>General>Invalid references to system libraries.

If you follow these guidelines, you will definitely help any users of your project that want to check out the code in their workspace. The compilation of your project becomes predictable and repeatable in any workspace. No more "I don't understand why my project doesn't compile when I checked it out from CVS....".

Hope this help you to setup your new projects or adjust the settings of your existing projects.

Quoi de neuf dans Helios?

La fondation Eclipse a sorti sa nouvelle version annuelle fin juin. Cette année, son nom est Hélios.
Comme d'habitude, la livraison fut faite le jour où elle était prévue et ce pour une 10e année consécutive.

Mais que peut-on trouver dans cette version Hélios?

Pour commencer, je dirais que le projet JDT s'est encore amélioré. Ajout d'un panneau avec plus de détails dans la vue de déboggage, détection des objets alloués mais non utilisés, compteur d'instances dans le deboggeur si la VM utilisée est supérieure ou égale à 1.6, possibilité de corriger plusieurs problèmes similaires en une seule opération (quickfix), quelques améliorations dans l'outil d'internationalisation ainsi que plusieurs améliorations notables dans le formatteur de code. À ce sujet là, le formateur peut maintenant est facilement désactivé pour une partie seulement d'une unité de compilation.
Pour plus de détails je vous invite à aller voir la démo sur le site Eclipse live.

Helios fournit une première intégration de l'outil de version distribué qu'est GIT dans Eclipse. Ce projet est appelé eGit. Le support est encore en phase de développement et requiert encore beaucoup d'usage de la ligne de commande. La prochaine version 0.9 prévue la première mise à jour d'Hélios en septembre devrait considérablement améliorer les choses. Pour une démo des possibilités actuelles, je recommande encore le site Eclipse Live avec cette démo.

La version Hélios apporte son lot d'amélioration dans p2. p2 fournit ses premières APIs et est maintenant beaucoup plus stable. Il devient très facile de mettre à jour sa version d'Eclipse au fur et à mesure que des mises à jour sont disponibles.

En lien avec les améliorations de p2, Eclipse fournit maintenant un moyen d'installer facilement de nouveaux composants dans Eclipse. L'outil s'appelle Eclipse MarketPlace et est directement disponible depuis le menu "Aide" ou "Help" en anglais.
Eclipse MarketPlace permet de rechercher des composants selon des mots clés et de les installer directement dans l'instance courante. C'est très pratique pour tester des composants. p2 permet également de tout désinstaller si un composant fonctionne mal ou ne répond pas aux attentes.

Un autre projet qui est également fourni avec Hélios est XText, un projet très intéressant qui peut s'avérer très utile à qui veut définir un nouvel éditeur pour Eclipse. Il fournit un ensemble d'outil pour définir sans trop de fatiguer un éditeur avec assistant de code et autres outils indispensables pour tout éditeur digne de ce nom. Voir le lien suivant: XText.

La version Hélios fournit également de nombreuses améliorations dans les projets existants tels que WTP, Mylyn, EMF,...

De mon point de vue c'est indéniablement une bonne version à utiliser. Le seul point que j'aimerais voir améliorer dans l'avenir avec la notion de "Release train" où plusieurs dizaines de projets sortent simultanément est la notion d'intégration. Le côté simultané ne devrait pas enlever que tous les projets ne sont pas encore proprement intégrés. L'interface utilisateur devient une véritable usine à gaz lorsque tous les projets sont installés dans la même instance d'Eclipse. Il reste encore à ce niveau beaucoup de travail. À la décharge des différents projets, cet aspect n'a jamais été un critère lors de la sortie d'une nouvelle version d'Eclipse. Je pense qu'avec la maturité de certains projets, il serait maintenant intéressant de faire des progrès à ce niveau. Ça ne faciliterait que davantage l'adoption d'Eclipse par un plus grand nombre de personnes.

Pour conclure je tiens à mentionner un petit problème qui survient sur Windows avec la dernière mise à jour de la machine virtuelle d'Oracle (anciennement Sun). La mise à jour 21 (JDK6_21) ne récupère pas correctement le paramètre pour la taille du PermGenSpace. Eclipse se retrouve alors à court de mémoire assez rapidement avec des symptômes qui vont du plantage au gel de l'interface sans aucun message d'erreur pertinent. Voir le lien suivant pour le bug qui traite du sujet: 319514 . Une nouvelle mise à jour d'Oracle devrait être disponible prochainement pour revenir à une version qui fonctionne sans aucun autre changement. Un correctif de la part d'Eclipse sera disponible pour la mise à jour 3.6.1.

Voilà j'espère que ce court message vous donnera le goût d'aller essayer Hélios et de nous dire ce que vous en pensez.

Pour Hélios, c'est par ici.

Bonne fin d'été!

Olivier

API Tooling at Eclipsecon

For the ones that still wonder what API Tooling is all about or what API Tooling can do for you, you should come to this presentation.
If you came to the presentation two years ago about the overview of API Tooling, you will learn more about API usage report and migration reports.


All questions and comments are welcome.

See you there.

JDT at Eclipsecon 2010

Hi,

If you want to find out more about what JDT has done for the Helios release, you might want to come to the following events at Eclipsecon 2010.
1) What's new in JDT? (lightning talk)
2) JDT Fundamentals (2h tutorial)

Of course I will be available for questions, discussions or comments during the whole conference. Send me a message if you want to meet there.

Thanks and see you soon at Eclipsecon.

Revue partielle de la version Galileo

Je vais vous parler de ce que je connais le mieux dans cette nouveau version d'Eclipse.

Je veux parler en premier lieu du projet API Tooling. Ce projet a été introduit dans la version 3.4 de manière très succincte. La version incluse dans Galileo est beaucoup plus aboutie.

API Tooling fournit de nombreuses tâches ant pour pouvoir faire des validations lors d'un build ant. Ces tâches ant sont notamment utilisées dans les builds Eclipse eux-même depuis plusieurs mois.

La validation peut également être faite au fur et à mesure du développement à l'aide d'un builder. Chaque projet PDE (pour l'instant les projet Java ne sont pas supportés) peut être converti vers API Tooling.
Une fois ceci fait il suffit de paramétrer une "baseline" qui sert de référence pour la définition des APIs afin d'avoir une validation faite par API Tooling.

La fonctionnalité que je préfère est la validation des librairies. Ceci permet de s'assurer lors du développement que les types, méthodes et champs utilisés depuis les librairies correspondent bien aux environnements d'exécution spécifiés pour le projet.

Prenons un exemple. Si je définis un projet avec comme environnement d'exécution J2SE-1.4, je ne suis pas supposé utiliser de méthodes définies uniquement en J2SE-1.5 ou JavaSE-1.6. Malheureusement Eclipse utilise comme JRE par défaut celui qui est utilisé pour démarrer Eclipse.
Donc si j'utilise une VM 1.6 pour démarrer Eclipse et qu'ensuite je crée un nouveau projet PDE, je vais avoir des librairies 1.6 sur le classpath de mon projet. Si je n'installe pas de JRE 1.4 correspondant à l'environnement d'exécution que je veux utiliser, je peux très facilement (en utilisant l'assistant de code (Ctrl + Space)) utiliser par mégarde une mauvaise méthode.
API Tooling va valider tous les références dans les librairies pour s'assurer que toutes existent dans l'environnement spécifié dans le fichier MANIFEST.MF et non uniquement dans les librairies utilisées sur le classpath.
Cela garantit qu'à l'exécution le fichier jar généré fonctionnera bien sur une VM 1.4. Cette fonctionnalité n'est pas spécialement intéressante quand un seul environnement d'exécution est spécifié, mais elle devient par contre essentielle quand plusieurs le sont en même temps comme:
J2SE-1.4, OSGi/Minimum-1.1, CDC-1.0/Foundation-1.0,...

Voilà pour API Tooling. Je vous encourage vraiment à convertir tous vos projets PDE pour utiliser cette fonctionnalité.

L'éditeur HTML de WTP a également fait des progrès notables dans la version 3.5 (Galileo).

JDT fournit de nouveaux outils pour retravailler le code, des améliorations dans le formatteur de code, des nouveaux outils pour aider à coder (assistant de codage). JDT reste un environnement de référence pour développer en Java sur un nombre de plateformes impressionnant.

L'intégration de Subeclipse dans le train Galileo simplifie grandement l'utilisation de référentiels SVN. Je ne suis pas très familier avec SVN lui-même, mais j'ai pu facilement accéder à des référentiels SVN et sauver mon code sans être trop perdu par rapport au support intégré avec le SDK pour CVS.

J'utilise aussi régulièrement Mylyn qui je l'avoue me simplifie grandement la vie en intégrant un client Bugzilla directement dans Eclipse. Ça fonctionne toujours aussi bien. Mylyn permet également de mieux cibler le code sur lequel on travaille et permet de partager ce "contexte" avec d'autres personnes.

Bref, Galileo est une nouvelle version qui vaut le détour. Il me reste encore à découvrir beaucoup d'autres projets intégrés avec Galileo: CDT, EMF, GEF, ...

Si vous avez des questions, n'hésitez pas!

Bonne découverte à tous!

Olivier