C# versus Java [Débat]

[rimram31]

Envoyé par _skip

Sur ce point, ça se passe au moins aussi bien que java, et même peut être mieux si on considère que tout le monde utilise les implémentations de référence. En ce sens, ce n'est pas comme dans java ou différents serveurs d'applications avaient toujours un petit truc à leur sauce. Même si depuis 1.5, ça c'est calmé.

La "portabilité" java a été longtemps plus un objectif qu'une réalité, combien de fois j'ai pesté après une application java (desktop) incapable de tourner sur la version installée sur ma machine et contraint d'avoir autant de versions de jvm que de soft a faire tourner ...

[_skip]

Envoyé par rimram31

La "portabilité" java a été longtemps plus un objectif qu'une réalité, combien de fois j'ai pesté après une application java (desktop) incapable de tourner sur la version installée sur ma machine et contraint d'avoir autant de versions de jvm que de soft a faire tourner ...

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.

[Nemek]

Envoyé par rimram31

La "portabilité" java a été longtemps plus un objectif qu'une réalité, combien de fois j'ai pesté après une application java (desktop) incapable de tourner sur la version installée sur ma machine et contraint d'avoir autant de versions de jvm que de soft a faire tourner ...

Tu confonds "rétrocompatibilité" et "portabilité". Cette première est clairement plus un fardeau et beaucoup de développeur débutant s'y trompe. J'ai même parfois des personnes avec un peu plus de bagage qui ne comprenne pas en quoi ca consiste.

[rimram31]

Envoyé par Nemek

Tu confonds "rétrocompatibilité" et "portabilité"...

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.

[_skip]

Envoyé par rimram31

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.

[Nemek]

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.

[_skip]

Envoyé par Nemek

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

[Nemek]

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.