Discussion :

[professeur shadoko]

Hello All
Ce message n'est pas tant une question qu'un coup de gueule .
ça doit faire la cinq ou sixième fois que je rentre dans les détails de projets open source bien connus pour utiliser à fond leur API ...
je suis sidéré par les lacunes de ces projets: pas la moindre doc et javadoc des APIs! tu vois une méthode et bien si tu veux comprendre ce qu'elle fait il faut lire le code source! et je parle de projets que tout le monde connait et utilise ....
Ce serait intéressant d'avoir un projet open source d'évaluation des projets open-source
Bien sûr la doc ne fait pas tout et n'est pas le seul critère d'évaluation de la qualité d'un code :
exemple: java.util.logging qui est bien documenté et est un joli caca de réalisation (c'est tellement caca que quand tu signales un bug l'équipe de maintenance le met à la poubelle de peur que ça soit trop de travail de re-architecturer le code).
En théorie on ne devrait pas réécrire soi même des codes qui sont utilisés et testés par des milliers d'utilisateurs .... et bien je reconnais que je suis quand même parfois tenté de le faire ... vade retro Satanas!
vous arrive-t'il de réécrire un code qui existe pourtant ailleurs ?

[OButterlin]

vous arrive-t'il de réécrire un code qui existe pourtant ailleurs ?

Je réécris systématiquement le code de mes collègues... ils codent avec les pieds tellement c'est mal écrit !

Bon, blague à part, et avant qu'un de mes collègue ne voit cette réponse, non, je ne réécrit pas les api standards, mais il m'ait déjà arrivé (rarement) d'aller voir comment c'est écrit quand j'ai une erreur inexplicable... et pas de piste...
Mais je n'ai jamais trouvé la source du dysfonctionnement dedans.

Quelle bibliothèque en particulier te pose problème ?

[professeur shadoko]

Il y a plusieurs catégories de problème:
- les codes que tu n'es certainement pas tenté de re-écrire mais qui font enrager parce qu'il te faut une journée pour pondre 10 lignes tellement les internes sont mal documentés (exemple: apache BCEL, Groovy -que j'adore pourtant-)
- les codes critiques qui font l'eau le gaz et l'électricité alors que tu ne veux précisément que du courant continu en 12 volts : là je réécris carrément si c'est critique.
- les codes pas hyper-critiques mais mal foutus: JUnit, java.util.logging, etc... (j'ai déjà re-écrit mon JUnit à moi tellement ça m'a énervé)

[tchize_]

On ne peux pas, en général, qualifier les api standard de java de mal documentées. Mal fichues oui, mais pas mal documentée. Et pourtant... J'ai déjà du aller voir le code pour savoir comment c'est fait. Mais effectivement, beaucoup de projet open sources n'étant pas backés par des grosses boites sont mal documenté, et pour, je pense, une raison code. C'est rare un programmeur qui sait écrire de la doc correctement. C'est rare un type sachant écrire de la doc voir dont c'est le métier et qui soit intéressé pour faire des heures sup à l'oeil. Je trouve, au contraire, que les api qui ont des gens appointés derrières (hibernate, spring par exemple) très longuement documentées.

Puis je peux t'assurer que j'ai déjà eu pas mal de librairies closed source payantes dans les mains documentées par des pinguoins polonais qui parlent l'indien . J'ai même eu, fasse à l'absence de documentation, le consultant de la boite qui nous vendait le package de librairies me dire très sérieusement: ho ben, vous décompilez. (La question était au passage "où est stockée la langue de l'utilisateur dans la session?")

[Gugelhupf]

Je pense qu'à part les projets les plus connus comme Hibernate, les projets libres ne sont pas tous bien documentés.
C'est dommage, il n'y a qu'à voir les API d'Apache POI, vraiment très mal foutu (documentation + code source).

La lib standard ne propose pas la crème des API, pour en citer deux :

• Calendar (voir Java 8 l'API date & time pour le remplaçant).
• l'API java.util.logging (je préfère utiliser log4j).

Sinon concernant la documentation de Sun/Oracle, désolé mais, il y n'y a qu'à voir la documentation de RMIClassLoader. Il n'y en a pas : http://docs.oracle.com/javase/7/docs...assLoader.html.
Quand tu vois les exemples de la doc PHP, avec pile poil les extraits de code que tu cherches (avec des couleurs en plus), c'est fait rêver.

PS: "Décompilez"... autant donner le code source xD J'ai remarqué que les décompilateurs Java se faisaient de plus en plus rares...

[tchize_]

Log4j & co sont tout à fait capable, il me semble, de gérer les output de java.util.logging. Justement, ils ne te lient à aucune api. Rien ne m'emm*** plus que de récupérer une lib pour me rendre compte qu'elle dépend de log4j, sa voisine de logback et slf4j ....
Quand aux api java 8, ben oui, encore heureux, POI continue de fonctionner avec les version antérieures du jdk :/

Et pour le RMIClassLoader, il me semble correctement documenté moi:
http://docs.oracle.com/javase/7/docs...assLoader.html

[Gugelhupf]

Je travaille en ce moment sur l'API Word et ActiveMQ (implémentation JMS) d'Apache, et je peux t'assurer que la doc est complètement moisie (pour ActiveMQ c'est 95% de blabla). Mais les sujets sur internet m'aident à m'en sortir sans trop de problème.

Pour RMIClassLoader j'appelle pas ça une doc, ça ne m'explique pas comment il faut s'y prendre pour l'utiliser correctement. Cela fait plusieurs mois que je suis sur cette classe, et je n'arrive toujours pas à la faire fonctionner.
Mon objectif est de télécharger l'interface Java du serveur (contrainte : le client ne doit pas avoir l'interface serveur qui hérite de Remote, mais la télécharger au démarrage), puis d'exécuter l'implémentation du Remote (UnicastRemoteObject) situé sur le serveur, mais j'ai des problème de SecurityManager. D'après ce que j'ai compris, il faut exécuter le client ou le serveur avec une commande spécifique (java.rmi.server.codebase quelque chose), mais je ne m'en sors pas vraiment.

PS: Par défaut, lorsqu'on fait du RMI, on crée une interface qui hérite de Remote, puis implémentation (UnicastRemoteObject) implémente cette interface qu'on a créé. Savais-tu que sans l'interface créé, RMI ne fonctionne pas ?
Niveau serveur ça compile, mais je me suis rendu compte, lorsque j'ai voulu faire un lookup au niveau du client afin de récupérer le stub dans un Object et d'utiliser l'introspection avec la classe Method dessus, que ça ne fonctionnait pas !
Même là on se rend compte que RMI est mal foutu. Comme quoi rien n'est parfait.

[tchize_]

Pour RMIClassLoader j'appelle pas ça une doc, ça ne m'explique pas comment il faut s'y prendre pour l'utiliser correctement.

Ce qui veux dire, probablement, que tu n'es pas censé l'utiliser directement. C'est juste un ClassLoader dont l'implémentation interne permet d'aller chercher le codebase sur le serveur. Ca fait plus de 10 ans que je n'ai pas fais de RMI, mais de mémoire ça marchait tout seul sans mettre une seule fois RMIClassLoader explicitement dans le code.

Maintenant c'est vrai qu'on pourrais avoir plus d'exemples, la pari chez sun / oracle. Le choix de sun a l'époque était de miser sur les livres et cours afin d'avoir un retour sur investissement. Mais d'une manière générale, j'ai toujours su me débrouiller avec les cours disponibles publiquement. D'un autre coté, je trouve que le langage et le fonctionnement de la jvm est extrèmement détaillé, on ne peux pas en dire autant de PHP que tu amène en comparaison. A plusieurs reprises, j'ai du lever l'une ou l'autre ambiguité, les la JLS a été d'un grand secours

[Gugelhupf]

Le RMI de base avec l'interface chez le client n'est pas difficile à mettre en place. Le RMI avancé avec téléchargement de l'interface chez le client (utilisation de RMIClassLoader) ce n'est pas la même chose

Je veux bien acheter leur livre mais je ne connais pas "the" livre de référence Java (lien de leur bookstore).
Je ne parlais pas du langage et de son implémentation, mais de la présentation de la doc, au niveau de la coloration syntaxique ils abusent. Les extraits de code de PHP ou cppreference.com sont pas mal.

[Gugelhupf]

Bon, et bien je viens d'avoir un cours particulier sur le sujet. Ce fut très instructif. Nous avons mis en place des fichiers de policy grâce aux outils du JDK.
On peut remarquer que le protocole RMI est bien plus complexe qu'on pourrait le croire. Je ne savais même pas que coté serveur, un port autre que celui de l'annuaire RMI, le port de négociation, était utilisé par le service RMI

[bouye]

Juste pour dire que coté client graphique, le code source des API publiques AWT, Swing et Java2D ne sont pas forcément des parangon de bonne pratique et de documentation. J'ignore quel est le pourcentage du code source de Swing qui est encore du code d'origine de IFC par Netscape et datant de 1996 mais c'est vraiment pas beau a voir a certains endroits. Mais bon, on peut aussi arguer qu'a l'origine tout cela n'etait pas du code OpenSource meme si le code source est dispo dans le JDK depuis belle lurette.

Le code source des API publique JavaFX est mieux organisé et semble plus propre mais n'est pas forcement mieux documenté pour autant et surtout il contient énormément de redondance et de duplicata (entre autre pour la création des propriétés en lecture seule ou l'initialisation différée pour éviter d'allouer trop de mémoire trop vite... - ou comment réinventer la roue a chaque déclaration de propriété...).