22 janvier 2013

pauvre Java

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 ...




 



5 commentaires:

Unknown a dit…

Salut,

il te manque aussi l'enum de JAX-RS javax.ws.rs.core.Response.Status qui n'a pas les préfixes SC mais pas tous les codes non plus...

ehsavoie a dit…

Sauf que si tu attends Java 5 pour avoir le code Tartempion qui manque tu es coincé. Donc tu refais tes propres codes pour etre indépendant de la version du code sous jacent :
java pour j(2)ee
j(2)ee pour jax-rs
etc.

Nicolas De Loof a dit…

@ehsavoie on est bien d'accord, c'est bien pour ça que je ne comprend pas que java 1.4 (4ème release tout de même) n'ai pas TOUS les codes prévus dans la RFC.

On en revient au manque de modularité de Java... et jigsaw arrivera beaucoup, beaucoup trop tard

ehsavoie a dit…

Tu veux dire dès Java 1.1 ;)
car HttpURLConnection c'est @since JDK 1.1 !!!
Là tu peux dire un vrai WTF

David a dit…

http://openjdk.java.net/jeps/110 mais il semble avoir raté le train de Java 8.