Je ne sais absolument pas si ça sera facile de corriger certains point sous Eclipse, je pense notamment au changement de visibilité.
Retour code JavaGL :
Déclaration de TOUTES les collections par des types concrets, non par des interfaces.
Ici, ça te fait comme problème de changer ET la déclaration ET l’initialisation.
Les collections n’ont pas de types génériques, ce qui implique de devoir obligatoirement passer par tout plein de instanceof pour ne pas se tromper dans l’ajout et le retrait.
Beaucoup de « magic number » => préférer des constantes nommées plutôt.
Exemple : if (string.length() < MAX_WORD_LENGTH) et if (string.length() < 12).
Le premier est plus parlant et permet de reutilizer la variable => plus facile à maintenir et faire évoluer (si la variable est bien utilisée pour un unique rôle)
Truc mineurs : a = a * norm => a *= norm. C’est pareil, plus court et souvent plus lisible (attention à ne pas en abuser).
Des assignements à l’indice d’une boucle « for ». Pas fan personnellement, je préfère éviter le plus possible, ça montre un souci d’algo, mais de temps en temps, c’est inévitable pour faire quelque chose de « court ». Peut-être passer par un itérateur, plutôt ?
Assignation d’une valeur à un paramètre de méthode. Ca, c’est personnel et dépend des équipes. Pour moi, les paramètres sont des constantes intouchables (dans le cas de type primitif), appel de méthode possibles.
Se renseigner sur la classe « MouseAdapter », et plutôt l’utiliser que « MouseListener » dans les cas qui correspondent (typiquement, pour toi : permet de définir 2 méthode au lieu de faire 6 méthodes dont 4 vides).
Ne pas hésiter à créer une classe réelle (interne ou non) au lieu d’une classe interne anonyme dans les cas de classe anonyme à forte complexité.
Il te manque pas mal d’annotation « @Override ». En soit, elle n’importe pas grand-chose (à ma connaissance), mais permettent de savoir directement que la méthode est redéfinie de quelque chose. Utile donc.
Des soucis avec « clone ».
• La première instruction doit plutôt être super.clone(), histoire de construire toute l’arborescence dans le cas de construction d’une classe fille d’un cloneable. Ce n’est pas obligatoire, juste que ne pas le mettre peut mener à des comportements étranges et difficilement compréhensibles.
• Beaucoup de méthodes « clone » dans des classes qui n’implémentent pas « cloneable », ce qui fait bizarre. L’implémentation de cloneable permet d’avoir une indication claire de la méthode, et de ne pas être au p’tit bonheur la chance.
Il reste des TODO (majoritairement générés par Eclipse).
Utilisation de Vector non générique. Franchement, remplace par des List à la déclaration, rend les génériques et tente de remplacer tes Vector par autre chose (ArrayList ou un autre conteneur plus adapté aux besoin).
Tu déclares tes tableaux comme en C :p
En Java, les crochets sont plutôt sur le type que sur la variable. Ca ne change strictement rien.
Pour la méthode « equals » avec des String, je te conseils très fortement d’invoquer la méthode sur la constante. Tu n’as ainsi pas besoin de faire de test de nullité avant. De plus, je te conseils aussi très fortement de mettre tes String constantes en static final, pas simplement en dur dans le code. Si elles sont utilisées à plusieurs endroits, ça permet d’éviter les erreurs de type, et quand il faut changer/renommer, c’est BEAUCOUP plus rapide.
Pour tester si une collection est vide, tu as la méthode isEmpty() généralement. Pas la peine de faire if (maCollec.size() == 0).
Concernant le « this », c’est une question de point de vue : pour moi, ne pas le mettre quand ce n’est pas nécessaire. Pour d’autre, le mettre tout le temps. Dans certaines classes, tu l’utilises de manière inutile, mais ça ne change strictement rien, si ce n’est l’esthétique.
Tu as beaucoup de parenthèses inutile pour le code, mais qui semble aider à la lecture (je n’ai pas tout regardé, mon inspection me retourne 643 de ces cas-là).
Question de goût aussi, mais quand il y a appel à des classes internes, tu as deux écoles : qualifier la classe interne par la classe l’englobant, ce qui permet de savoir où elle est, ce qui est fait, si sa place ici est logique, mais alourdit le code. Il y a l’autre, de simplement l’utiliser comme une classe. Je préfère le premier, mais c’est une question de goût.
Je te conseils aussi de t’intéresser au for each, qui est très pratique 
Tu as la branche « else » de ta méthode « process » dans la classe JGL_Motion_Slide qui ne sert à rien (ligne 113). Déroule le code, tu devrais comprendre.
Tu as pas mal d’assignation après test de nullité. C’est une question de goût, mais tu pourrais mettre un opérateur ternaire ici. Attention, ceux-ci rendent facilement le code illisible.
Classe « JGL_Motion_Bounce », ligne 71-72. Tu fais un loops = 0 puis un while (loops == 0) => tu peux remplacer par un « while(true) ». Vu que je ne sais pas ce que tu veux faire ici, concrétement, ce n’est pas forcément une bonne idée de faire une boucle pseudo-infinie. Vérifie bien que tu en sortiras obligatoirement avec le code de sortie que tu as prévue (si ce n’est pas déjà fait).
Selon les conventions Java, les variables statiques sont plutôt mises avec CE_TYPE_DE_NOMENCLATURE. De plus, tu as pas mal de variable statique que tu considères comme des constantes qui ne sont pas déclarées en tant que telle (il manque le mot-clef « final »).
Les trucs comme « if (resultat == true), ça ne sert à rien
Autant remplacer par « if (resultat) », non ?
Pour ton switch de JGL_3DMatrix, je te conseils de mettre les valeurs en constantes, plutôt que de simple valeurs avec un commentaire non-javadoc à côté.
Tu as des switch sans branche « default » (classes JGL_ImageLoader et JGL_ImageScaler), vérifie bien que tu es obligatoirement dans une des branches, et que c’est strictement impossible sinon.
Sinon, rajoute plutôt un case « default ».
Tu as des « return ; » à la fin de méthode sensée retourner void. Ca ne sert à rien (classes JGL_Data3D et JGL_ReaderObj).
Ta gestion des Exceptions est calamiteuse. Ne fais JAMAIS de « catch (Exception) » ni de « throw new Exception() ». Utilise TOUJOURS des exceptions qui ont un véritables sens. Tu as fait, par exemple :
Catch (FileNotFoundException e)
{
e.printStackTrace() ;
throw new Exception(« Fichier introuvable ») ;
}
Pourquoi ? Pourquoi ne simplement pas avoir fait remonter l’exception en le déclarant dans le prototype de la méthode ?
De plus, Exception est EXTRÊMEMENT vaste. En faisant un catch (Exception), tu prends les IO, FileNotFound, NullPointer … tu prends beaucoup trop.
À un autre endroit, tu catch une exception pour la lancer immédiatement après. À quoi sert de la prendre ?
Mon inspection me dit que ta méthode « addBone » retourne absolument toujours « true ». Je ne sais pas si c’est vraiment le cas.
La méthode « getMaterials » dans JGL_ReaderObj ne lance jamais d’exception Exception.
Tu fais des accès directs à des attributs déclarés en tant que « private », pas une bonne pratique du tout. Passe plutôt par des accesseurs.
Tu as des visibilités « package » (i.e. : absence de modificateur de visibilité). Personnellement, je fais en sorte de ne pas en avoir, mais c’est aussi un peu à la discrétion.
Pour un bon principe d’encapsulation, mets tout tes attributs en « private » et utilise des accesseurs (getter/setter). Cela permet de bien délimiter les responsabilités de chacun, et de pouvoir facilement limiter les effets de bord (si c’est en lecture seule, le getter retourne une version non-modifiable de l’objet, par exemple).
J’ai tout plein de « uncheckedWarning » lié a l’absence de test avant de retirer d’une liste et de transtyper.
Tu as un constructeur publique dans la classe JGL_Loop, sauf que celle-ci est abstraite, donc au mieux doit en avoir un en protected.
Tu fais un tout petit peu d’auto—(un)boxing inutile.
Tu fais des copies de tableau « à la main ». Utilise plutôt System.arrayCopy
Pareil pour tableau vers collection. Utilise Collections.addAll
par contre je me demande si ça a une réelle utilité vu qu'à peu près toutes les config supportent l'accélération matérielle... 
![[-ArK-]](https://image.jeuxvideo.com/avatars/0/-ark-_-1390817458-b.jpg)
. 
... 
(le chieur!).
