C'est quand même assez réussi...
Autant dans le monde du j2ee je veux bien reconnaître qu'il faille être très prudent avec les versions du JDK et des serveurs d'application, autant en j2se j'ai quasiment jamais vu de problème.
Il y a des exceptions bien sûr, l'installeur de SAP en est un bel exemple mais à qui attribuer la faute? Je trouve honnêtement que depuis la 1.5, c'est quand même pas difficile d'avoir une application desktop portable en java. Il suffit de se gaffer sur deux ou trois petites choses liées à l'OS mais c'est largement faisable.
Sur l'exemple que je donne peut-être mais pas dans l'idée que je voulais exposer. Les n versions étaient toutes "conformes", sans aucun souci de compatibilité ou de portabilité, mais l'anomalie provenait de légères différences d'implémentations, hors spécification, qui peuvent avoir un impact sur le code final.
J'ai eu un exemple amusant entre je crois une 1.2 et une 1.3, une erreur dans une chaine de format utilisant une directive inexistante. Le souci c'est que la spec n'avait pas précisé comment se comporter dans ce cas, en 1.2 ça fait pas grand chose mais sans erreur, la version suivante une Exception était générée.
Je comprends déjà mieux, même si heureusement les exemples restent limités. Pour ma part j'ai goûté aux joies des différences d'implémentation avec les API xml pour SAX. Surtout que pour le coup, l'implémentation de référence du JDK (un xerces batardisé) est resté buggée d'une fuite de mémoire pour la majorité de la 1.6, soit plusieurs années.
Mais bon, on reste assez bien lotis.
rimram31 > 1.2 et 1.3 doivent être de lointain et de mauvais souvenirs ... Je pense qu'il faudrait également se défaire de 1.4 et voir 1.5.
_skip > L'avantage de beaucoup d'API de Java c'est de reposer sur le pattern SPI et que si les implémentations ne te conviennent pas, il suffit d'en fournir une (par exemple Apache Xerces 2.8 ou Saxon)
Concernant la version embarquée par défaut, c'est bien une Xerces mais une version figée. Pour retrouver la version, il me semble qu'il faut fouiller la JSR de la version majeure de Java qui figera une version de JAXP et ensuite il faudra fouiller la JSR de cette version de JAXP pour trouver l'implémentation de référence. Sinon il me semble que Xerces (à moins que ce ne soit Xalan) possède une classe "Version" avec des constantes.
Cette approche est certes assez flexible mais pour moi elle a beaucoup plus d'inconvénients que d'avantages dans la pratique. Tu écris plus de code, il y a toujours 2-3 checked exceptions de plus que nécessaire à cause du lookup de l'implémentation et de la configuration du parser et au final tu finis souvent par utiliser directement les classes de ton implémentation pour profiter de ses fonctionnalités avancées non standards.
Enfn bon, je trouve que ça semble pratique sur papier mais sur le terrain c'est loin d'être génial et ça amène plus de problèmes que ça n'en résoud. Je t'oblige pas à être d'accord mais c'est l'opinion que j'en ai.
Bah en fait je suis entièrement d'accord :p Mais l'avantage c'est que tu as tout de même une base saine et commune, pour les besoins simples.
Et c'est grâce à ces nombreux "standards" que tu as d'autres produits dérivés comme JAXB, FOP, framework Web, etc.
Concernant le lookup avec l'interface Service, il est transparent.
Bonjour,
Je fait une formation en langage python car je suis débutante dans la programmation. Par la suite je voudrais apprendre le langage C# .
Est une bonne transition ?!
J aurai plus facile par la suite à apprendre le langage C#
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager