Un scan de la base de registre devrait suffire, encore que je ne sais pas si c'est possible avec Java. Et je ne sais pas si "non polluant" et "base de registres" sont compatibles.
La base de registre n'est pas accessible directement en Java, il faut passer par des librairies natives. Pour le support des raccourcis sauce Windows, on a été obligé d'en arriver là :-/ En meme temps on a bien limité la casse et on écrit rien dans la base de registre et au final IzPack reste bien "non polluant" sur un système Win32. De plus le support des raccourcis (et donc le besoin d'une librairie native) est optionnel. En meme temps, rien ne garanti qu'un soft aura une entrée dans la base de registre. Par exemple si tu dépend de Tomcat, il faut le chercher sur le disque, pas dans la base de registre. Donc au final c'est un problème assez compliqué :-/
Je ne sais pas si les MD5 seraient vraiment à envisager. Pardonne-moi si je me trompe, mais les MD5 servent à vérifier l'intégrité d'un fichier et non sa version, donc il faudrait comparer les MD5Sums de toutes les versions possibles d'un fichier. Est-ce que l'on peut avoir toutes les MD5Sum possibles d'un fichier? Si oui, est-ce raisonnable comme solution?
On peut considérer que si on cherche un fichier en particulier pour tester la présence d'un logiciel, les différentes versions seront différentes. Par exemple si je cherche la présence de Jakarta Ant, je vais chercher un fichier nommé "ant.jar". C'est lui qui contient les classes Java de Ant, donc d'une version à l'autre il est forcémment différent. Donc sa signature MD5 sera différente. Pour que l'on ait un conflit de signatures (2 fichiers différents avec la meme signature), la probabilité est très faible. Un MD5 permettrait donc d'identifier une version de fichier. Est-ce raisonnable de stocker différentes signatures ? Non :-) Tout ça pour dire que ce style de dépendance est très difficile à vérifier. Tout ce que l'on peut faire est implémenter des heuristiques assez lourdes, ce n'est pas très raisonnable.
C'est quoi "en O(0.5)"?
C'est quelque chose d'impossible :-) Plus sérieusement, reportes-toi à un cours de complexité algorithmique. Des exemples, meme si c'est hors-sujet :
a = 2 + b;
c = (a == 3) ? (5 * x) : 0;
Est de complexité O(1)
for (i = 0; i < 100; ++i)
std::cout << "Coucou !" << endl;
[^] # Re: Que pour Java :-(
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 5.
La base de registre n'est pas accessible directement en Java, il faut passer par des librairies natives. Pour le support des raccourcis sauce Windows, on a été obligé d'en arriver là :-/ En meme temps on a bien limité la casse et on écrit rien dans la base de registre et au final IzPack reste bien "non polluant" sur un système Win32. De plus le support des raccourcis (et donc le besoin d'une librairie native) est optionnel. En meme temps, rien ne garanti qu'un soft aura une entrée dans la base de registre. Par exemple si tu dépend de Tomcat, il faut le chercher sur le disque, pas dans la base de registre. Donc au final c'est un problème assez compliqué :-/
Je ne sais pas si les MD5 seraient vraiment à envisager. Pardonne-moi si je me trompe, mais les MD5 servent à vérifier l'intégrité d'un fichier et non sa version, donc il faudrait comparer les MD5Sums de toutes les versions possibles d'un fichier. Est-ce que l'on peut avoir toutes les MD5Sum possibles d'un fichier? Si oui, est-ce raisonnable comme solution?
On peut considérer que si on cherche un fichier en particulier pour tester la présence d'un logiciel, les différentes versions seront différentes. Par exemple si je cherche la présence de Jakarta Ant, je vais chercher un fichier nommé "ant.jar". C'est lui qui contient les classes Java de Ant, donc d'une version à l'autre il est forcémment différent. Donc sa signature MD5 sera différente. Pour que l'on ait un conflit de signatures (2 fichiers différents avec la meme signature), la probabilité est très faible. Un MD5 permettrait donc d'identifier une version de fichier. Est-ce raisonnable de stocker différentes signatures ? Non :-) Tout ça pour dire que ce style de dépendance est très difficile à vérifier. Tout ce que l'on peut faire est implémenter des heuristiques assez lourdes, ce n'est pas très raisonnable.
C'est quoi "en O(0.5)"?
C'est quelque chose d'impossible :-) Plus sérieusement, reportes-toi à un cours de complexité algorithmique. Des exemples, meme si c'est hors-sujet :
Est de complexité O(1)
Est de complexité O(n)