new Blog( perso );

Je rebondis sur un tweet de Julien Dubois pour verser une larme sur Java, et la façon dont la plateforme arrive à partir en sucette d'elle même.

Prenons un exemple excessivement simple : la gestion des status HTTP. Ca semble vraiment le truc de base, non ?

Le runtime Java SE propose HttpURLConnection. Déjà on se demande d'un point de vue puriste de l'OO pourquoi la "connection" porte ces constantes et pas une classe de constantes, mais bon, java 1.0 a été pondu à l'arrache, passons.

Arrive Java EE, sensé être basé sur Java SE (non ?), mais évidemment on a une autre classe parce que c'est vachement plus drôle HttpServletResponse. Ici les codes retour sont portés par un objet qui matérialise une réponse HTTP, c'est un tout petit peu plus logique, mais ça reste très con de dupliquer. Ne soyons pas médisant, cette classe ajoute d'indispensables constances :

• SC_CONTINUE
• SC_SWITCHING_PROTOCOLS
• SC_FOUND
• SC_TEMPORARY_REDIRECT
• SC_REQUESTED_RANGE_NOT_SATISFIABLE
• SC_EXPECTATION_FAILED

et aussi, redéfinit les constantes existantes avec des noms un peu plus explicites :  HTTP_REQ_TOO_LONG -> SC_REQUEST_URI_TOO_LONG. C'est juste un peu dommage d'avoir conservé ce préfixe "SC_" qui nous rappelle les règles de nommage du siècle dernier.

Mettons que Java EE a eu besoin de ces nouveaux codes, non prévus la Java SE. Pourquoi ne pas avoir ajouté au backlog Java SE "ajouter les codes manquants du standard HTTP  à HttpURLConnection" - je veux dire, il y a un spécification pour HTTP, ces codes ne sont pas juste issus d'un reverse engineering à la con !

D'ailleurs, de son côté, commons-http a créé sa propre classe de constantes HttpStatus avec références explicites aux RFC 1945 / 2518 / 2616 (HTTP 1.0, WebDAV et HTTP 1.1), tout en nous coltinant ce magnifique préfixe "SC_", nous avons donc sans doute affaire à des développeurs issus de la même formation ;P

Et bien sur, l'équipe Spring qui crache dans la soupe Java EE depuis tant d'année ne s'est pas privée de sa propre version HttpStatus, sans les références RFC mais aussi sans préfixes pourris.

Bref, cet exemple est révélateur de l'écosystème Java : Java SE et Java EE qui n'arrivent même pas à être cohérents, Apache qui a longtemps proposé des projets génériques (les fameux commons-*) venant compléter les manques de la plateforme, Spring qui ajoute son grain de sel...

Même sur un exemple aussi simpliste que la liste des codes prévus par une spécification officielle, c'est la misère. Alors pour un StringUtils ...