il soit nécessaire de changer la signature de la classe...
Justement c'est là le problème : les clauses "throw machinException" ne font pas parti de la signature. Le runtime ne détectera donc pas d'incohérence et acceptera d'utiliser cette lib au même titre que l'ancienne. Et on se retrouve avec une exception non checkée. Quel va être le comportement de l'appelant qui va se bouffer cette nouvelle exception ?
lors de l'installation chez le client t'es obligé d'utiliser le class path
C'est bien ce que je dis : c'est pas terrible :) C'est quand même plus simple d'avoir un système de versioning avec la possibilité de faire coexister plusieurs classes "identiques" au niveau de la signature, mais pas au niveau des versions.
L'exemple des méthodes virtuelle dans les liens que j'ai cité sont également un on bon exemple de choses "dangereuses" en Java lors de maj/déploiement/utilisation.
[^] # Re: L'avenir des langages compilés pour les gros projets
Posté par TImaniac (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 2.
Justement c'est là le problème : les clauses "throw machinException" ne font pas parti de la signature. Le runtime ne détectera donc pas d'incohérence et acceptera d'utiliser cette lib au même titre que l'ancienne. Et on se retrouve avec une exception non checkée. Quel va être le comportement de l'appelant qui va se bouffer cette nouvelle exception ?
lors de l'installation chez le client t'es obligé d'utiliser le class path
C'est bien ce que je dis : c'est pas terrible :) C'est quand même plus simple d'avoir un système de versioning avec la possibilité de faire coexister plusieurs classes "identiques" au niveau de la signature, mais pas au niveau des versions.
L'exemple des méthodes virtuelle dans les liens que j'ai cité sont également un on bon exemple de choses "dangereuses" en Java lors de maj/déploiement/utilisation.