:: Enseignements :: ESIPE :: E4INFO :: 2017-2018 :: Java Avancé ::

Projet d'IR2/IG2

Calendrier
6 octobre: Maven et premiers tests avec ASM

Votre projet doit être créé sur gitlab, il être capable d'exécuter un test simple avec ASM qui récupère le nom du fichier Java correspondant au fichier .class, et les champs ou méthodes qui sont déclarées protected.
Le projet doit être builder et le test exécuté avec Maven.

13 octobre: mise en place JUnit 5 et intégration des tests avec ASM.

Convertir le premier test en test unitaire JUnit 5 au lieu d'utiliser un main(). Ajouter des tests qui vérifient les règles:

sur les instanceof (récupérer aussi le numéro de la ligne correspondante dans le fichier .java)
et les classes abstraites.

Faire en sorte, en créant vos propres classes qui encapsulent l'usage d'ASM, que si l'on spécifie que l'on veut vérifier plusieurs règles, la vérification soit faite en une passe sur toutes les classes. Lancer les tests unitaires avec Maven. Configurer Gitlab pour qu'il exécute les tests à chaque commit.

20 octobre: mise en place des plugins, mise en place de Spring, premier service Web.

Faire en sorte que les tests deviennent des plugins, utiliser le java.util.ServiceLoader pour les charger. Les tests JUnit exécutent maintenant les plugins. Configurer Spring pour que l'on puisse lancer le serveur Web à partir de la ligne de commande. Configurer Maven pour qu'il build la partie Spring aussi. Choisir la bibliothèque JSON que vous allez utiliser (en expliquant vos critères de sélection). Faire un premier service web qui affiche un Hello World au format JSON.
Vérifier qu'un instanceof dans une méthode equals (qui redéfinit la méthode equals de java.lang.Object) ne déclenche pas la règle instanceof.
Ajouter une nouvelles règle qui vérifie que si une classe implante uniquement les méthodes (d'instance) déclarées dans ses super types (super classes et super interfaces) alors cette classe est une classe anonyme (où interne si il y a plusieurs interfaces/ou une interface et de l'héritage).

27 octobre: module Java 9, rapport en XML et affichage simple avec vuejs

Découper votre projet en plusieurs modules Java (chaque plugin doit être un module).
Faire en sorte que l'on puisse choisir quels ensembles de règles on exécute et configurer ceux-ci sur la ligne de commande.
Sortir un rapport au format XML (le format n'est pas imposé !) indiquant le résultat de chaque règle.
Configurer Maven pour qu'il puisse builder un projet vuejs et faire un Hello World en utilisant vuejs (qui appelle le Hello World de votre service Web).
Ajouter la règle qui vérifie que l'on n'utilise pas d'implantation d'une collection (ArrayList, HashSet, mais aussi celles qu'un utilisateur pourrait écrire) en tant que type de retour ou paramètre d'une méthode publique.
Ajouter un test qui vérifie l'ensemble des règles foraxproof sur votre code.

3 novembre: première intégration verticale.

Faire en sorte d'afficher les informations d'un rapport XML dans votre interface vuejs.
Écrire la doc de développement.
Le projet marche maintenant de bout en bout.

10 novembre: rapport avec SQLite, affichage code source (vuejs)

Permettre d'utiliser une base de donnée SQLite ou le fichier XML pour sortir le rapport.
Intégrer les morceaux de sources (.java) avec les informations du rapport (XML ou SQLite) dans vuejs (il faut alors indiquer où se situe le fichier zip, par ex. src.zip qui contient les .java)
Mettre à jour la doc de développement.
Ajouter une rêgle qui vérifie que les méthodes font pas plus de 8 lignes.

17 novembre: foraxproof sur des artefacts sur Maven Central.

Faire en sorte que l'on puisse faire fonctionner foraxproof sur des artefacts stockés sur Maven Central. Attention, on ne vous demande de ne pas stocker les .class sur le disque mais de faire tourner votre moteur de règle sur les .class lors du download. Les fichiers de sources (les .java) devront eux être téléchargés et stockés sur le disque par le serveur si on lance celui-ci. Mettre à jour la doc de développement. Ajouter une annotation @ForaxProof qui permet de ne pas activer une rêgle, par exemple, @ForaxProof sur un champ protected ne sera pas reconnu comme une erreur par la rêgle sur le mot clé protected.

24 novembre: version bêta.

Ajouter un règle qui détecte si les méthodes publiques renvoient null en utilisant le package analysis d'ASM. Écrire la doc utilisateur. Mettre à jour la doc de développement. La bêta peut avoir des bugs mais doit contenir toutes les fonctionnalités.

1er décembre: version finale.

Corriger les bugs restants.

Exercice 1 - foraxproof

Le but de ce projet est d'implanter un outil qui vérifie certaines propriétés sur un code écrit en Java.
Java est un langage créé en 1995; le type d'applications, ainsi que la façon d'écrire des applications à évolué depuis sa création. L'idée de l’outil foraxproof est de vérifier que les bonnes pratiques actuelles sont observées lors de la création et la maintenance de projets utilisant le langage Java.
De plus, dans le but de favoriser l'auto-formation des utilisateurs de foraxproof, l’outil devra aussi fournir des explications indiquant pourquoi une façon d'écrire les choses n'est pas correcte et quelle est la bonne pratique correspondante avec un exemple.
Enfin, au lieu de travailler sur le code Java en lui-même, foraxproof travaille sur le bytecode (le format des .class) - donc après la compilation - car il est plus aisé et plus rapide de travailler sur le code binaire après le passage du compilateur.
foraxproof

est un outil en ligne de commande qui prend en paramètre un ensemble de jars et analyse ceux-ci dans le but de vérifier les bonnes pratiques,
possède une architecture à base de plugins qui permet de spécifier les règles qui devront être vérifiées par le code Java,
effectue une analyse du bytecode en une (ou deux cf plus tard) passe, en gardant le moins de chose possible en mémoire,
possède un mode "serveur" qui permet d'afficher sous forme d'une application Web les résultats de l'analyse et de conseiller l'utilisateur lorsque de mauvaises pratiques sont détectées.

Le projet est composé de deux parties, un outil en ligne de commande qui analyse le bytecode et un serveur REST qui sert de back-end à l'application Web qui permet de visualiser le résultat de l'analyse et les recommandations.

Configuration
Il n'y a pas de configuration à proprement parler, à part les arguments passés sur la ligne de commande.
Sécurité
La connexion au serveur ne doit se faire qu'en HTTPS, (HTTP ne doit pas être supporté). Pour cela, lors du premier lancement du serveur, il sera demandé un secret à l'utilisateur qui sera utilisé pour générer ce qu'il faut pour établir le tunnel HTTPS.
Plugins
Vous devez utiliser le ServiceLoader du JDK 9 et les modules pour déclarer et découvrir les différents plugins.

Pour la lecture du bytecode vous utiliserez la librairie ASM. Pour comprendre le fonctionnement d'ASM, vous pouvez vous référer au guide d'utilisation.

Les données d'une analyse sont exportées par le serveur sous forme de services Web respectant la technologie REST. Le serveur Web est imposé, il s'agit de Spring Reactive Web, que vous configurerez en utilisant Spring Boot 2 (Le site https://start.spring.io/ vous permet d'avoir une base de départ).

Pour la sérialisation/dé-sérialisation JSON des requêtes, vous utiliserez l'API de parsing JSON de votre choix.

Pour la présentation de l'application Web, on vous demande de n'utiliser la librairie vuejs en faisant un frontal Web le plus simple possible.

Le code du projet est hébergé sur gitlab.com. Le projet doit utiliser Maven comme outil de build.

Les test unitaires doivent être effectués avec Junit 5, vous pouvez vous référer au guide d'utilisation.

Ce projet est évalué par les enseignants de Java, la dernière semaine du trimestre sous forme d'une soutenance de 20 minutes (on discutera architecture et code).

Concurrence
L'analyse du bytecode doit être effectuée en parallèle, en utilisant les techniques vues dans le cours de concurrence.
Java Avancé
Le programme doit être écrit en utilisant correctement les différents concepts vus lors du cours de Java Avancé (sous-typage, polymorphisme, lambda, classes internes, exceptions, types paramétrés, collections, entrées/sorties et réflexion).
Pour vous aider, si vous ne respectez pas les indications de "mort imminente" suivantes, 2 points seront retirés pour chaque indication non respectée.
Ces indications (pour la plupart) font partie de ce que devrait tester foraxproof par défaut.
- Il ne doit pas y avoir d'erreur lorsque l'on passe foraxproof.
- Il ne doit pas y avoir de warnings lorsque l'on charge le code dans Eclipse.
- Il ne doit pas y avoir de warnings lorsque l'on compile avec javac.
- Dans un module, les packages d'implantation ne doivent pas être exportés et requires transitive doit être utilisé là où c'est nécessaire.
- Il ne doit pas y avoir de raw types, de @SuppressWarning non justifié, de cast non justifié.
- Il ne doit pas y avoir de champs ou méthodes protected.
- Il ne doit pas y avoir d'instanceof/switch/if...else sur des types là où il est possible d'utiliser le polymorphisme.
- Chaque interface devra être nécessaire.
- Aucune classe abstraite ne doit être publique ou utilisée comme un type.
- Chaque méthode devra être appelée (pas de code mort).
- Aucune méthode ne doit pas faire plus de 8 lignes sans une vraie justification.
- Il est interdit d'utiliser des champs static typés par un objet (pas de globale), seule les constantes (static final) de type primitif sont autorisées.