Discussion :

[Melchisedec]

Bonjour,
Je me pose la question de savoir si l'on peut faire prudemment des patches d'une appli en fournissant uniquement les classes qui ont été modifiées.

Voici mon problème plus en détail.
J'ai développé un client lourd java que j'ai livré à un département chargé d'en faire des fichiers d'installation *.msi pour installation sur les postes des utilisateurs (vous allez, dire que c'est con de faire des *.msi alors qu'on peut déployer aisément avec Java web Start, mais voyez-vous, c'est pas moi qui décide ce genre de choses .....).
Bref, revenons à nos moutons :
Une fois que les *.msi sont réalisés et déployés sur les postes des testeurs et que certains bugs sont signalés, Le client pour qui je travaille m'impose de liver des "patches" consititués uniquement des *.class correspondant aux sources que j'ai modifiés lors de la correction des bugs.

Je suis contre ce principe parce que je pense qu'il peut arriver que des classes qui n'ont pas été compilées ensembles ne marchent pas bien.

D'ailleurs, il y a depuis 2 jours un nouveau bug est apparu après la livraison d'un de ces patches. Ce bug ne se produit pas sur mon poste parce que justement (selon moi) mes classes ont été compilées ensembles.
Le bug en question est que l'URL d'un fichier de config n'a pas pu être construite.
Le code dont je me sers pour pour charger ce fichier de conf a toujours marché. Ce code renvoie un objet de type java.net.URL. C'est le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

this.getClass().getClassLoader().getResource(configFileFullPath)

où configFileFullPath est un String représentant le chemin du fichier à partir de la racine des package, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"com/mycompany/project/aspect/config.xml"

Savez-vous si j'ai raison ?
Est-ce que de façons générale (en dehors de RMI) des classes qui n'ont pas été compilées ensembles peuvent conduire -au moment de l'exécution- à un comportement erroné ? Pourriez-vous argumentez votre avis par des exemples ?
Avez-des références à ce propos que je peux consulter sur le net ?
Merci

[yann2]

bonjour

Ben non ! Le fonctionnement ne peut être erroné (sauf pour les pb de versions dont tu parles dans un contexte RMI).

Exemple :
- Quand tu codes, tu ne recompiles pas tous le JDK !
- Tu utilises toujours des libs externes que tu ne recompiles jamais !

Bref, je pense que ça devrait fonctionner...

Mais bon...

[Satch]

Bref, je pense que ça devrait fonctionner...
Mais bon...

Tu penses ? Pas très convaincant comme réponse ça.

J'avoue que la question m'interresse aussi.

Je me demande si le compilateur ne ferait pas quelques optimisations.

J'aimerai beaucoup que quelqu'un puisse dire catégoriquement si oui ou non on peut juste donner les .class qui ont changé.

[Melchisedec]

Je suis d'accord avec Satch.
J'aurais souhaité une réponse plus précise et si possible avec des références disponibles sur le net, par exemple.

[Scorpyosis]

Moi je suis de l'avis de yann2, je ne vois pas en quoi le fait de compiler les classes de façon séparément les rendraient inutilisable, ca va à l'encontre du bon sens. Comme le fait remarquer yann2, vous n'avez pas a recomplier tout le jdk pour pouvoir l'utiliser ! Si on suit votre idée, si on veut utiliser une lib il faut avoir les sources, sinon ca ne marcherait pas...etrange non ?! Quand au compilo, il fait certes des optimisation mais rien dans ce genre, sinon ca deviendrait ingérable. Quand a ton probleme es tu sur que vos environnement de travail soit les meme ? meme arborescence de fichier ?

[MangeurVasqué]

Il faut quand même s'assurer que les nouveaux binaires soient compatibles avec l'environnement d'exécution et peut-être bien aussi avec les anciens.

Melchisedec, tu n'as pas une trace ?

[adiGuba]

Salut,

Moi je suis de l'avis de yann2, je ne vois pas en quoi le fait de compiler les classes de façon séparément les rendraient inutilisable, ca va à l'encontre du bon sens.

Il y a un cas ou cela peut poser problème : si on utilise des constantes avec des types primaires ou des String, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
public class Constante {
    public static final String NOM = "valeur";
    public static final int INTKEY = 0;
}

En effet lorsqu'on utilise une de ces constantes dans une autre classe, le lien avec la classe Constante est perdu à la compilation, ainsi le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
System.out.println(Constante.NOM);
System.out.println(Constante.INTKEY);

Est compilé de la mnière suivante (les références sotn remplacé par leurs valeurs) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
System.out.println("valeur");
System.out.println(0);

De ce fait, si les valeurs des contantes sont modifiées, toutes les classes qui utilisent ces constantes doivent être recompilé...

Nota: Si on utilise des objets il n'y a pas de remplacement, la référence est bien conservé à la compilation...


Est-ce que c'est ton cas ???

a++

[Melchisedec]

Si on suit votre idée, si on veut utiliser une lib il faut avoir les sources, sinon ca ne marcherait pas...etrange non ?!

Je crois que tu n'as pas bien saisi, Scorpyosis. Les classes d'une lib ont déja été compilées ensemble. Quand tu te sers d'une lib, tu ne fais qu'importer les classes de cette lib et t'en servir.

Or ici, je parle de modifier quelques sources de mon projet, les recompiler et livrer aux utilisateurs seulement les *.class des sources modifiés de sorte que ces *.class remplacent leurs anciennes version. On retrouvent alors chez les utilisateurs un ensemble de classes qui n'ont pas été compilées ensemble.
De toute façon, je souhaiterais avoir des réponses plus précises qu'une simple opinion basée sur le bon sens. L'idée bon sens est quelque chose de très personnel.
Avez-vous des références reconnues où une explication plus rigoureuse ?

[Xavinou]

Est ce que tu es sur que le code livré par le département chargé du deployement n'est pas offusqué ?

Sinon il n'y a pas de raison que tes nouvelles classes ne marchent pas, sauf (bien sûr) si leurs interfaces ont été modifiées.