Le runtime java (rien avoir avec le classpath, mais alors vraiment rien) est plutot pas mal concu en soi.
C'est un truc vieux de 20 ans, dans l'ensemble ca s'en sort plutot bien. Ok, ya des boulets a droite a gauche, genre la classe Date qui est deprecated a 99%, ca serait sympa d'avoir des versions immutables des collections, ou une version mutable de String.
Par dessus, l'autoboxing a foutu la zone, et la tendance de sun a rajouter du sucre syntaxique au compilo ammene des problemes chiant (comme une for(Object object : list) qui te pete une NPE quand list est null, ou a+ b qui fait pareil, merci l'autoboxing).
Le truc de java, c'est le monde entreprise. Des applis critiques massivement complexes destinees a interagir avec d'autres applis massivement complexes sans que les deux se connaissent.
Le but de java, c'est pas de rendre le developement simple/facile, c'est de rendre le developement de gros bouzin super complique possible.
D'ou des designs gigantesques, et dans un design gigantesque, ya toujours qq trucs qui partent un peu couille, et ca donne sa reputation a java.
Ton exemple xml te fait peut etre marrer, mais ya une palanquee de providers xml differents, et oui, ca a une utilite.
En contraste, le monde java sait aussi faire des trucs super simples. Pour du json avec jaxson, tu ponds du json (ou du xml) avec tres exactement 0 lignes de code.
Return monObjet, pouf il est serialise par jersey, en xml ou en json, merci les annotations.
Le coup de la map, je sais pas d'ou tu viens ni qui t'as appris ton design objet, mais environ 100% des langages objets suivent ce pattern pour les collections… Une interface definit l'api, le runtime fournit de bonnes implementations de base, et libre a toi d'implementer ce dont t'as besoin.
Faut etre un peu tare (ou idiot) pour mettre en dur les collections typees contre une classe concrete…
[^] # Re: Bof...
Posté par groumly . En réponse au journal PHP, A Fractal Of Bad Design. Évalué à 4.
Le runtime java (rien avoir avec le classpath, mais alors vraiment rien) est plutot pas mal concu en soi.
C'est un truc vieux de 20 ans, dans l'ensemble ca s'en sort plutot bien. Ok, ya des boulets a droite a gauche, genre la classe Date qui est deprecated a 99%, ca serait sympa d'avoir des versions immutables des collections, ou une version mutable de String.
Par dessus, l'autoboxing a foutu la zone, et la tendance de sun a rajouter du sucre syntaxique au compilo ammene des problemes chiant (comme une for(Object object : list) qui te pete une NPE quand list est null, ou a+ b qui fait pareil, merci l'autoboxing).
Le truc de java, c'est le monde entreprise. Des applis critiques massivement complexes destinees a interagir avec d'autres applis massivement complexes sans que les deux se connaissent.
Le but de java, c'est pas de rendre le developement simple/facile, c'est de rendre le developement de gros bouzin super complique possible.
D'ou des designs gigantesques, et dans un design gigantesque, ya toujours qq trucs qui partent un peu couille, et ca donne sa reputation a java.
Ton exemple xml te fait peut etre marrer, mais ya une palanquee de providers xml differents, et oui, ca a une utilite.
En contraste, le monde java sait aussi faire des trucs super simples. Pour du json avec jaxson, tu ponds du json (ou du xml) avec tres exactement 0 lignes de code.
Return monObjet, pouf il est serialise par jersey, en xml ou en json, merci les annotations.
Le coup de la map, je sais pas d'ou tu viens ni qui t'as appris ton design objet, mais environ 100% des langages objets suivent ce pattern pour les collections… Une interface definit l'api, le runtime fournit de bonnes implementations de base, et libre a toi d'implementer ce dont t'as besoin.
Faut etre un peu tare (ou idiot) pour mettre en dur les collections typees contre une classe concrete…