:: Enseignements :: Master :: M1 :: 2007-2008 :: Génie Logiciel ::

---

Java Enhanced Research Compiler (jerc)

---

Le but de ce projet est de comprendre la structure du compilateur Java, OpenJDK javac, après tout le compilateur est aussi un programme. Donc le but de ce projet est de faire du rétro-ingénierie sur le code de javac en créant les diagramme UML correspondant au code puis de modifier le code pour ajouter une nouvelle fonctionalité.
Attention le sujet est en cours de rédaction.

---

Nouvelle fonctionalité

1. Emoticode
   Comme indiqué dans le blog de Chet Haase http://weblogs.java.net/blog/chet/archive/2006/12/closures_making.html, le but est de permettre d'utiliser les smileys en tant qu'identificateur en Java.
   Attention, le code normal devra continuer à compiler donc soit certain emoticons seront interdit ou mieux désactivés suivant le context.
   Par exemple:

   for(;;) {   // il n'y a pas d'emoticon ici
   ...
   }
   			   

   
   Cette modification est facile.
2. Thread local field
   Le but est de permettre la déclaration de champs locaux à une thread en ajoutant un nouveau mot-clé "threadlocal". Le compilateur transforme ce champs en utilisant la classe java.lang.ThreadLocal.
   Il serait bien que thread local ne soit un mot-clé que lors de la déclaration des champs et donc utilisatable comme identificateur autre part pour éviter les problèmes de compatibilité.
   Cette modification n'est ni facile ni difficile.
3. SelfType aka type of this
   Le but est de permettre d'exprimer le type de this comme d'écrit dans le blog de peter ahé, http://blogs.sun.com/ahe/entry/selftypes
   Pour éviter des problèmes de mot-clé, on utilisera "this" pour indiquer le type de "this" (le même mot-clé). De plus, pour éviter de faire des choses trop compliqué, on ne permettra "this" (en tant que type) uniquement en tant que type de retour.
   Cette modification est difficile.
4. Type safe array of generics
   Actuellement, il est impossible de créer un tableau de type paramétré. L'idée est de lever cette contrainte, techniquement, créer un tableau de type paramétré n'est pas unsafe si l'on respecte la règle suivante :

   			   if U is an array of parametrized type, the compiler should only emit a warning, if :
                     T is Object, Cloneable, Serializable or
                     T is an array of V which is not parametrized or
                     T is an array of raw type. 
                     T is an unbound wildcard.
   			  

   Donc la modification consiste à permettre l'allocation des types paramétrés et à ajouter des warnings "unsafe cast" suivant cette règle.
   Cette modification n'est ni facile ni difficile.
5. Auto-null
   Il est des fois assez pratique de mettre les références à null une fois que l'objet n'est plus utilisé pour qu'il puisse être garbage collecté avant la fin de la méthode. Le but de cette extension consiste à repérer pour les variables locales stockant des références sur des objets la dernière fois où celles-ci sont utilisée (cette information est déjà calculée par le compilateur) et à insérer une instruction mettant la référence à null.
   Par exemple:

   			    VeryBigObject vbo=new VeryBigObject();
   			    fbo.doSomething(); // insérer un fbo=null, ici
   			    system.out.println("toto");
   			  

   En fait, il est même possible d'insérer le fbo=null, (astore de null) avant l'appel à doSometing() si fbo est déjà sur la pile.
   Cette modification n'est ni facile ni difficile.
6. @CatchReturn
   Il n'est pas possible actuellement d'obliger un utilisateur d'une méthode à récupérer la valeur de retour pourtant dans la cas d'une méthode sans effet de bord comme String.toUpperCase cela n'a pas de sens de ne pas récupérer cette valeur. Le but est donc d'ajouter une annotation @CatchReturn (que l'on déclarera sur les méthodes) dans java.lang et de modifier le compilateur pour que celui-ci vérifie que si une méthode possède cette annotation alors sa valeur est bien utilisée.
   Cette modification est facile.
7. @CheckedException
   Le but est d'indiquer au compilateur que certaine exception qui hérite de runtime exception doivent être quand même gérer comme si elle héritait uniquement d'exception i.e en forçant à avoir soit un try/catch au site d'appel ou un throws. On se propose d'ajouter une annotation @CheckedException dans java.lang pour indiquer ce genre d'exception. Le compilateur au lieu de signaler une erreur signalera juste un warning "checkedexception" qui pourra être supprimer par @SuppressWarnings.
   Attention, il y a quelque règles à respecter :
   1. Il n'est pas possible de mettre @CheckedException sur autre chose que des RuntimeException.
   2. Si une méthode lève une exception marqué avec @CheckedException, une méthode qui redéfinira cette méthode devra aussi lever une @CheckedException. Basiquement cela veux dire que si une exception est une @CheckedException toutes ses sous-classes le sont aussi.
   3. Si une méthode ne lève pas d'exception, une méthode redéfinie ne pourra pas lever d'exception marqué @CheckedException.
   
   Cette modification n'est ni facile ni difficile.
8. Array to List boxing
   Il n'est pas possible facilement de convertir un tableau d'objet, Object[], en son équivalent, utilisant les collections de Java, java.util.List. Le but est d'implanter un mécanisme équivalent au mécanisme de boxing/unboxing permettant de convertir n'importe quel tableau d'objet en son équivalent en List. La partie un peu compliqué est l'unboxing de n'importe quelles listes.
   Cette modification n'est ni facile ni difficile.

Les contraintes

• Par défaut, votre javac patché fonctionne normalement. Pour activer la nouvelle fonctionnalité, il faut utiliser -XDblahblah sur la ligne de commande. Je vous laisse choisir le nom de l'option.
• Chaque modification est "backward compatible", cela veux dire que le code déjà existant en Java doit continuer à fonctionner comme avant même si la nouvelle fonctionalité est activé.

Obtenir les sources et compiler

Details du rendu

References

---