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