Discussion :

[lvr]

Hello,
Mon application java utilise des ressources qu'elle doit extraire en locale depuis son jar.
La condition pour faire l'extraction est qu'une copie locale n'existe pas déjà.
Oui mais... si la nouvelle version de l'application vient avec une nouvelle version de cette ressource, héhé, elle n'est pas remplacée puisqu'elle existe déjà.
Donc la solution serait de vérifier également, si la ressource du jar n'est pas postérieure à la copie locale. Et là, je bloque. Comment faire ?
Merci à tous.

[tchize_]

La question est surtout comment tu arrive à mettre une date correcte au fichier dans le jar, via ton build process. La date dans le jar est bien souvent la date du build puisque les fichiers. Bien qu'on puisse ensuite extraire cette date depuis le jar, il serait bien plus simple de stocker un numéro de version dans une ressource de ton jar et de l'utiliser pour comparer à la dernière version que tu as extraite.

[hwoarang]

Pour ce type de probleme, utiliser la date du fichier est une mauvaise solution. Comme te l'a dit tchize, il vaut mieux que tu partes sur un systeme de versionnage (l'ideal étant dans le fichier lui meme si tu maitrises le contenu) ou bien sur un serveur ou autre.
N'oublies pas que la date du fichier peut etre changée à la main et que cela peut foutre en l'air ton algo. Par exemple, si j'edite un fichier d'une ancienne version - ce qui remettra sa date à aujourd’hui alors que tu avais bidouillé pour que ce soit la version du jar, ca risque de faire utiliser le mauvais fichier. Et, apres avoir vu que j'ai tout cassé, si je remets le contenu original du fichier (mais la date sera toujours à aujourd’hui, je ne comprendrais pas que l'appli ne marche pas.

Bref, utiliser la date n'est pas une bonne idée. En plus, l'utilisation de version te permettra de mieux gérer la retro-compatibilité