J'ai une question à propos des JTree. Une JList est la représentation
graphique d'une List, mais un JTree ça se sauvegarde dans quelle
structure de données?
Je pose la question car, dans ce groupe, on m'avait conseillé, il y a
quelque temps, de séparer les données en mémoire de leur représentation
graphique. C'est ce que je fais car c'est une bonne façon de programmer.
Mais pour sauver un JTree en mémoire, pour avoir une structure de données
sur la quelle on peut faire des calculs, ça se passe comment? Comment
faire pour avoir une structure de données que je pourrais ensuite sauver
sur disque et restaurer dans la mémoire à volonté?
Le Wed, 21 Feb 2018 23:23:28 +0100, Samuel DEVULDER a écrit :
Le 21/02/2018 à 01:50, jp a écrit :
Je ne pense pas car l'objet Date fournit un long qui est un nombre de millisecondes. Pour planter le logiciel, il faudrait créer 2 Chapter dans la même milliseconde. Ce sera impossible car le logiciel ne permettra pas de générer des Date lui-même.
Fais des tests avec des outils automatisé genre Sikuli, et tu va voir que dans ce cas ton outil créera 200 ou 300 chapitres à la seconde. La classe java UUID fournit en principe un ID unique à chaque appel. https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html sam.
Merci pour l'info. Mais mon programme ne pourra pas générer 300 chapitres à la seconde car ils sont créés par l'utilisateur à l'aide d'un menu "new chapter". La seconde manière d'en créer un est en faisant un drag&drop en maintenant la touche Ctrl appuyée. Là aussi, pas moyen de créer plusieurs chapitres dans la même milliseconde... La remarque de ylur est bonne, c'est pourquoi j'ai rajouté quelques lignes de code pour prévoir l'imprévisible. :)
Je trouve au contraire que la solution proposée par Samuel est intéressante, bien que je n'ai pas lu toutes les détails du fonctionnement (comment la fonction parvient à générer un id globalement unique)... je regarderai la RFC un de ces jours. C'est très simple à mettre en œuvre, l'id est unique (pas un bricolage qui essaie de parvenir à un résultat similaire mais seulement dans certaines conditions). Ton appli va évoluer, avoir une solution simple et fiable pour ce genre de problème est très important, sinon tu mines le terrain sur lequel tu marches et tu t'exposes à des ennuis aléatoires (un gros problème dès qu'un logiciel prend un peu d'ampleur). Si tu ne veux pas te retrouver assailli de toutes part par les ennuis, mieux vaut avoir des solutions claires aux problèmes qui se posent.
Le 22 Feb 2018 04:16:04 GMT
jp <bloiiing.invalid@yahoo.com> a écrit :
Le Wed, 21 Feb 2018 23:23:28 +0100, Samuel DEVULDER a écrit :
> Le 21/02/2018 à 01:50, jp a écrit :
>> Je ne pense pas car l'objet Date fournit un long qui est un nombre
>> de millisecondes. Pour planter le logiciel, il faudrait créer 2
>> Chapter dans la même milliseconde. Ce sera impossible car le
>> logiciel ne permettra pas de générer des Date lui-même.
>
> Fais des tests avec des outils automatisé genre Sikuli, et tu va
> voir que dans ce cas ton outil créera 200 ou 300 chapitres à la
> seconde.
>
> La classe java UUID fournit en principe un ID unique à chaque appel.
>
> https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html
>
> sam.
Merci pour l'info. Mais mon programme ne pourra pas générer 300
chapitres à la seconde car ils sont créés par l'utilisateur à l'aide
d'un menu "new chapter". La seconde manière d'en créer un est en
faisant un drag&drop en maintenant la touche Ctrl appuyée. Là aussi,
pas moyen de créer plusieurs chapitres dans la même milliseconde...
La remarque de ylur est bonne, c'est pourquoi j'ai rajouté quelques
lignes de code pour prévoir l'imprévisible. :)
Je trouve au contraire que la solution proposée par Samuel est
intéressante, bien que je n'ai pas lu toutes les détails du
fonctionnement (comment la fonction parvient à générer un id
globalement unique)... je regarderai la RFC un de ces jours.
C'est très simple à mettre en œuvre, l'id est unique (pas un bricolage
qui essaie de parvenir à un résultat similaire mais seulement dans
certaines conditions).
Ton appli va évoluer, avoir une solution simple et fiable pour ce genre
de problème est très important, sinon tu mines le terrain sur lequel tu
marches et tu t'exposes à des ennuis aléatoires (un gros problème dès
qu'un logiciel prend un peu d'ampleur). Si tu ne veux pas te retrouver
assailli de toutes part par les ennuis, mieux vaut avoir des solutions
claires aux problèmes qui se posent.
Le Wed, 21 Feb 2018 23:23:28 +0100, Samuel DEVULDER a écrit :
Le 21/02/2018 à 01:50, jp a écrit :
Je ne pense pas car l'objet Date fournit un long qui est un nombre de millisecondes. Pour planter le logiciel, il faudrait créer 2 Chapter dans la même milliseconde. Ce sera impossible car le logiciel ne permettra pas de générer des Date lui-même.
Fais des tests avec des outils automatisé genre Sikuli, et tu va voir que dans ce cas ton outil créera 200 ou 300 chapitres à la seconde. La classe java UUID fournit en principe un ID unique à chaque appel. https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html sam.
Merci pour l'info. Mais mon programme ne pourra pas générer 300 chapitres à la seconde car ils sont créés par l'utilisateur à l'aide d'un menu "new chapter". La seconde manière d'en créer un est en faisant un drag&drop en maintenant la touche Ctrl appuyée. Là aussi, pas moyen de créer plusieurs chapitres dans la même milliseconde... La remarque de ylur est bonne, c'est pourquoi j'ai rajouté quelques lignes de code pour prévoir l'imprévisible. :)
Je trouve au contraire que la solution proposée par Samuel est intéressante, bien que je n'ai pas lu toutes les détails du fonctionnement (comment la fonction parvient à générer un id globalement unique)... je regarderai la RFC un de ces jours. C'est très simple à mettre en œuvre, l'id est unique (pas un bricolage qui essaie de parvenir à un résultat similaire mais seulement dans certaines conditions). Ton appli va évoluer, avoir une solution simple et fiable pour ce genre de problème est très important, sinon tu mines le terrain sur lequel tu marches et tu t'exposes à des ennuis aléatoires (un gros problème dès qu'un logiciel prend un peu d'ampleur). Si tu ne veux pas te retrouver assailli de toutes part par les ennuis, mieux vaut avoir des solutions claires aux problèmes qui se posent.
Yliur
Le 22 Feb 2018 04:10:06 GMT jp a écrit :
Le Wed, 21 Feb 2018 15:16:41 +0100, Yliur a écrit :
Une manière plus fiable de créer des ids serait de détecter le plus grand id associé à un chapitre et de gérer un compteur via une méthode synchronisée par exemple. Ce n'est pas très difficile. Ce n'est sans doute pas très urgent, mais note de te repencher sur la question pas trop tard, sinon tu vas oublier et ton appli risque de casser un peu aléatoirement.
Et si je fais ça? {...] public Date newDate() { Date d = new Date(); try { //Thread.sleep(100); // suspendu pendant 100 millisecondes wait(100); } catch(InterruptedException e) { System.out.println(e.getMessage()); } return d; } [...] Au départ j'avais synchronisé la méthode newDate() mais je pense que ce n'est pas la peine.
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas où tu as un programme qui crée des chapitres (Samuel cite un cas intéressant : le cas d'un outils réalisant des tests automatiques si je ne m'abuse) : ce processus sera lent pour rien. La synchronisation pour générer des ids c'est toujours bien : ça évite les ennuis quand tu parallélises quelque chose dans ton code et ça ne te coûte rien. Remarque annexe : Thread.sleep me paraît plus approprié que wait, qui sert à autre chose en principe (blocage/déblocage entre fils d'exécution).
Le 22 Feb 2018 04:10:06 GMT
jp <bloiiing.invalid@yahoo.com> a écrit :
Le Wed, 21 Feb 2018 15:16:41 +0100, Yliur a écrit :
> Une manière plus fiable de créer des ids serait de détecter le plus
> grand id associé à un chapitre et de gérer un compteur via une
> méthode synchronisée par exemple. Ce n'est pas très difficile.
>
> Ce n'est sans doute pas très urgent, mais note de te repencher sur
> la question pas trop tard, sinon tu vas oublier et ton appli risque
> de casser un peu aléatoirement.
Et si je fais ça?
{...]
public Date newDate() {
Date d = new Date();
Au départ j'avais synchronisé la méthode newDate() mais je pense que
ce n'est pas la peine.
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le
cas où tu as un programme qui crée des chapitres (Samuel cite un cas
intéressant : le cas d'un outils réalisant des tests automatiques si
je ne m'abuse) : ce processus sera lent pour rien.
La synchronisation pour générer des ids c'est toujours bien : ça évite
les ennuis quand tu parallélises quelque chose dans ton code et ça ne te
coûte rien.
Remarque annexe : Thread.sleep me paraît plus approprié que wait, qui
sert à autre chose en principe (blocage/déblocage entre fils
d'exécution).
Le Wed, 21 Feb 2018 15:16:41 +0100, Yliur a écrit :
Une manière plus fiable de créer des ids serait de détecter le plus grand id associé à un chapitre et de gérer un compteur via une méthode synchronisée par exemple. Ce n'est pas très difficile. Ce n'est sans doute pas très urgent, mais note de te repencher sur la question pas trop tard, sinon tu vas oublier et ton appli risque de casser un peu aléatoirement.
Et si je fais ça? {...] public Date newDate() { Date d = new Date(); try { //Thread.sleep(100); // suspendu pendant 100 millisecondes wait(100); } catch(InterruptedException e) { System.out.println(e.getMessage()); } return d; } [...] Au départ j'avais synchronisé la méthode newDate() mais je pense que ce n'est pas la peine.
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas où tu as un programme qui crée des chapitres (Samuel cite un cas intéressant : le cas d'un outils réalisant des tests automatiques si je ne m'abuse) : ce processus sera lent pour rien. La synchronisation pour générer des ids c'est toujours bien : ça évite les ennuis quand tu parallélises quelque chose dans ton code et ça ne te coûte rien. Remarque annexe : Thread.sleep me paraît plus approprié que wait, qui sert à autre chose en principe (blocage/déblocage entre fils d'exécution).
Samuel DEVULDER
Le 22/02/2018 à 05:16, jp a écrit :
car ils sont créés par l'utilisateur à l'aide d'un menu "new chapter".
C'est là que ton analyse est fausse. Ca n'est pas forcément un humain à la vitesse limitée qui effectue un appel au menu. Il y a d'autres façon que d’appeler un menu via un processus physique. Cela s'automatise très bien (voir la classe java Robot) et ca va très, très vite. Si un utilisateur devant faire des choses répétitives avec ton outil se fait un prog à lui avec le robot, tu va te retrouver à devoir gérer 200 ou 300 appels du menu à la seconde. Il faut pouvoir tenir la charge. On ne peut jamais assumer que les appels graphiques se font "lentement". C'est juste faux. sam.
Le 22/02/2018 à 05:16, jp a écrit :
car ils sont créés par l'utilisateur à l'aide d'un menu "new
chapter".
C'est là que ton analyse est fausse. Ca n'est pas forcément un humain à
la vitesse limitée qui effectue un appel au menu. Il y a d'autres façon
que d’appeler un menu via un processus physique. Cela s'automatise très
bien (voir la classe java Robot) et ca va très, très vite. Si un
utilisateur devant faire des choses répétitives avec ton outil se fait
un prog à lui avec le robot, tu va te retrouver à devoir gérer 200 ou
300 appels du menu à la seconde. Il faut pouvoir tenir la charge. On ne
peut jamais assumer que les appels graphiques se font "lentement". C'est
juste faux.
car ils sont créés par l'utilisateur à l'aide d'un menu "new chapter".
C'est là que ton analyse est fausse. Ca n'est pas forcément un humain à la vitesse limitée qui effectue un appel au menu. Il y a d'autres façon que d’appeler un menu via un processus physique. Cela s'automatise très bien (voir la classe java Robot) et ca va très, très vite. Si un utilisateur devant faire des choses répétitives avec ton outil se fait un prog à lui avec le robot, tu va te retrouver à devoir gérer 200 ou 300 appels du menu à la seconde. Il faut pouvoir tenir la charge. On ne peut jamais assumer que les appels graphiques se font "lentement". C'est juste faux. sam.
jp
Le Wed, 21 Feb 2018 23:23:28 +0100, Samuel DEVULDER a écrit :
La classe java UUID fournit en principe un ID unique à chaque appel. https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html
J'ai regardé. Ça a l'air bien mais je n'ai pas compris comment on l'utilise... J'y reviendrai pour essayer de comprendre plus tard. Pour l'instant je m'en tiens à mon système de dates. En fait, je ne vois pas l’intérêt de créer 300 chapitres à la seconde. Pourquoi un utilisateur voudrait-il faire ça? Ça n'a aucun intérêt...
Le Wed, 21 Feb 2018 23:23:28 +0100, Samuel DEVULDER a écrit :
La classe java UUID fournit en principe un ID unique à chaque appel.
J'ai regardé. Ça a l'air bien mais je n'ai pas compris comment on
l'utilise... J'y reviendrai pour essayer de comprendre plus tard. Pour
l'instant je m'en tiens à mon système de dates.
En fait, je ne vois pas l’intérêt de créer 300 chapitres à la seconde.
Pourquoi un utilisateur voudrait-il faire ça? Ça n'a aucun intérêt...
Le Wed, 21 Feb 2018 23:23:28 +0100, Samuel DEVULDER a écrit :
La classe java UUID fournit en principe un ID unique à chaque appel. https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html
J'ai regardé. Ça a l'air bien mais je n'ai pas compris comment on l'utilise... J'y reviendrai pour essayer de comprendre plus tard. Pour l'instant je m'en tiens à mon système de dates. En fait, je ne vois pas l’intérêt de créer 300 chapitres à la seconde. Pourquoi un utilisateur voudrait-il faire ça? Ça n'a aucun intérêt...
jp
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas où tu as un programme qui crée des chapitres (Samuel cite un cas intéressant : le cas d'un outils réalisant des tests automatiques si je ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques. Et puis le logiciel en question n'est pas prévu pour être utilisé par des robots. A+
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas
où tu as un programme qui crée des chapitres (Samuel cite un cas
intéressant : le cas d'un outils réalisant des tests automatiques si je
ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques. Et
puis le logiciel en question n'est pas prévu pour être utilisé par des
robots.
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas où tu as un programme qui crée des chapitres (Samuel cite un cas intéressant : le cas d'un outils réalisant des tests automatiques si je ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques. Et puis le logiciel en question n'est pas prévu pour être utilisé par des robots. A+
David Larochette
Le Sat, 24 Feb 2018 08:01:03 +0000, jp a écrit :
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas où tu as un programme qui crée des chapitres (Samuel cite un cas intéressant : le cas d'un outils réalisant des tests automatiques si je ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques.
Tu pourrais aussi ajouter à ta clé une valeur aléatoire. Ainsi, l'unicité de la clé ne repose pas entièrement sur l'horodatage. C'est d'ailleurs souvent la méthode utilisée pour créer les uuid.
Et puis le logiciel en question n'est pas prévu pour être utilisé par des robots.
Pour l'instant, mais il vaut mieux éviter de présager d'un futur qu'on ne connait pas. Un exemple simple serait par exemple que tu veuilles implémenter une fonction d'importation d'un autre format. Tu te retrouverais bien dans le cas d'un programme qui génère des chapitres rapidement.
Le Sat, 24 Feb 2018 08:01:03 +0000, jp a écrit :
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le
cas où tu as un programme qui crée des chapitres (Samuel cite un cas
intéressant : le cas d'un outils réalisant des tests automatiques si je
ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques.
Tu pourrais aussi ajouter à ta clé une valeur aléatoire. Ainsi, l'unicité
de la clé ne repose pas entièrement sur l'horodatage. C'est d'ailleurs
souvent la méthode utilisée pour créer les uuid.
Et puis le logiciel en question n'est pas prévu pour être utilisé par
des robots.
Pour l'instant, mais il vaut mieux éviter de présager d'un futur qu'on ne
connait pas. Un exemple simple serait par exemple que tu veuilles
implémenter une fonction d'importation d'un autre format. Tu te
retrouverais bien dans le cas d'un programme qui génère des chapitres
rapidement.
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas où tu as un programme qui crée des chapitres (Samuel cite un cas intéressant : le cas d'un outils réalisant des tests automatiques si je ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques.
Tu pourrais aussi ajouter à ta clé une valeur aléatoire. Ainsi, l'unicité de la clé ne repose pas entièrement sur l'horodatage. C'est d'ailleurs souvent la méthode utilisée pour créer les uuid.
Et puis le logiciel en question n'est pas prévu pour être utilisé par des robots.
Pour l'instant, mais il vaut mieux éviter de présager d'un futur qu'on ne connait pas. Un exemple simple serait par exemple que tu veuilles implémenter une fonction d'importation d'un autre format. Tu te retrouverais bien dans le cas d'un programme qui génère des chapitres rapidement.
jp
Le Sat, 24 Feb 2018 12:59:05 +0000, David Larochette a écrit :
Le Sat, 24 Feb 2018 08:01:03 +0000, jp a écrit :
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas où tu as un programme qui crée des chapitres (Samuel cite un cas intéressant : le cas d'un outils réalisant des tests automatiques si je ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques.
Tu pourrais aussi ajouter à ta clé une valeur aléatoire. Ainsi, l'unicité de la clé ne repose pas entièrement sur l'horodatage. C'est d'ailleurs souvent la méthode utilisée pour créer les uuid.
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas encore compris la manière de l'utiliser. Par contre rajouter un nombre aléatoire je sais très bien le faire. Merci pour l'idée.
Et puis le logiciel en question n'est pas prévu pour être utilisé par des robots.
Pour l'instant, mais il vaut mieux éviter de présager d'un futur qu'on ne connait pas. Un exemple simple serait par exemple que tu veuilles implémenter une fonction d'importation d'un autre format. Tu te retrouverais bien dans le cas d'un programme qui génère des chapitres rapidement.
Ok. J'ai compris que je vais rajouter quelques lignes pour générer un nombre aléatoire et le problème sera réglé. A+
Le Sat, 24 Feb 2018 12:59:05 +0000, David Larochette a écrit :
Le Sat, 24 Feb 2018 08:01:03 +0000, jp a écrit :
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le
cas où tu as un programme qui crée des chapitres (Samuel cite un cas
intéressant : le cas d'un outils réalisant des tests automatiques si
je ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques.
Tu pourrais aussi ajouter à ta clé une valeur aléatoire. Ainsi,
l'unicité de la clé ne repose pas entièrement sur l'horodatage. C'est
d'ailleurs souvent la méthode utilisée pour créer les uuid.
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas
encore compris la manière de l'utiliser. Par contre rajouter un nombre
aléatoire je sais très bien le faire.
Merci pour l'idée.
Et puis le logiciel en question n'est pas prévu pour être utilisé par
des robots.
Pour l'instant, mais il vaut mieux éviter de présager d'un futur qu'on
ne connait pas. Un exemple simple serait par exemple que tu veuilles
implémenter une fonction d'importation d'un autre format. Tu te
retrouverais bien dans le cas d'un programme qui génère des chapitres
rapidement.
Ok. J'ai compris que je vais rajouter quelques lignes pour générer un
nombre aléatoire et le problème sera réglé.
Le Sat, 24 Feb 2018 12:59:05 +0000, David Larochette a écrit :
Le Sat, 24 Feb 2018 08:01:03 +0000, jp a écrit :
Le Thu, 22 Feb 2018 10:05:49 +0100, Yliur a écrit :
Dommage d'ajouter un délai, pour la réactivité de l'appli et pour le cas où tu as un programme qui crée des chapitres (Samuel cite un cas intéressant : le cas d'un outils réalisant des tests automatiques si je ne m'abuse) : ce processus sera lent pour rien.
Pas pour rien, puisque ça évitera la création de deux Date identiques.
Tu pourrais aussi ajouter à ta clé une valeur aléatoire. Ainsi, l'unicité de la clé ne repose pas entièrement sur l'horodatage. C'est d'ailleurs souvent la méthode utilisée pour créer les uuid.
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas encore compris la manière de l'utiliser. Par contre rajouter un nombre aléatoire je sais très bien le faire. Merci pour l'idée.
Et puis le logiciel en question n'est pas prévu pour être utilisé par des robots.
Pour l'instant, mais il vaut mieux éviter de présager d'un futur qu'on ne connait pas. Un exemple simple serait par exemple que tu veuilles implémenter une fonction d'importation d'un autre format. Tu te retrouverais bien dans le cas d'un programme qui génère des chapitres rapidement.
Ok. J'ai compris que je vais rajouter quelques lignes pour générer un nombre aléatoire et le problème sera réglé. A+
Samuel DEVULDER
Le 24/02/2018 à 16:00, jp a écrit :
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas encore compris la manière de l'utiliser.
heu... elle est où la difficulté d’appeler UUID.randomUUID() qui te retouurne un ID unique ? C'est carrément plus court et mois casse c*uilles que de s'em*rder avec Thread.sleep(), Object.wait() et autres appels à Math.random(). sam.
Le 24/02/2018 à 16:00, jp a écrit :
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas
encore compris la manière de l'utiliser.
heu... elle est où la difficulté d’appeler UUID.randomUUID() qui te
retouurne un ID unique ? C'est carrément plus court et mois casse
c*uilles que de s'em*rder avec Thread.sleep(), Object.wait() et autres
appels à Math.random().
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas encore compris la manière de l'utiliser.
heu... elle est où la difficulté d’appeler UUID.randomUUID() qui te retouurne un ID unique ? C'est carrément plus court et mois casse c*uilles que de s'em*rder avec Thread.sleep(), Object.wait() et autres appels à Math.random(). sam.
jp
Le Sat, 24 Feb 2018 16:19:24 +0100, Samuel DEVULDER a écrit :
Le 24/02/2018 à 16:00, jp a écrit :
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas encore compris la manière de l'utiliser.
heu... elle est où la difficulté d’appeler UUID.randomUUID() qui te retouurne un ID unique ? C'est carrément plus court et mois casse c*uilles que de s'em*rder avec Thread.sleep(), Object.wait() et autres appels à Math.random().
Oui si c'est comme ça d'accord... Mais est-ce que que l'objet aléatoire retourné est basé en partie sur la date pour éviter d'en avoir 2 identiques? A+
Le Sat, 24 Feb 2018 16:19:24 +0100, Samuel DEVULDER a écrit :
Le 24/02/2018 à 16:00, jp a écrit :
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas
encore compris la manière de l'utiliser.
heu... elle est où la difficulté d’appeler UUID.randomUUID() qui te
retouurne un ID unique ? C'est carrément plus court et mois casse
c*uilles que de s'em*rder avec Thread.sleep(), Object.wait() et autres
appels à Math.random().
Oui si c'est comme ça d'accord... Mais est-ce que que l'objet aléatoire
retourné est basé en partie sur la date pour éviter d'en avoir 2
identiques?
Le Sat, 24 Feb 2018 16:19:24 +0100, Samuel DEVULDER a écrit :
Le 24/02/2018 à 16:00, jp a écrit :
Ça c'est plus faisable que d'utiliser la classe UUID, car je n'ai pas encore compris la manière de l'utiliser.
heu... elle est où la difficulté d’appeler UUID.randomUUID() qui te retouurne un ID unique ? C'est carrément plus court et mois casse c*uilles que de s'em*rder avec Thread.sleep(), Object.wait() et autres appels à Math.random().
Oui si c'est comme ça d'accord... Mais est-ce que que l'objet aléatoire retourné est basé en partie sur la date pour éviter d'en avoir 2 identiques? A+
Samuel DEVULDER
Le 25/02/2018 à 12:16, jp a écrit :
Oui si c'est comme ça d'accord...
Ah ben voilà!
Mais est-ce que que l'objet aléatoire retourné est basé en partie sur la date pour éviter d'en avoir 2 identiques?
Peu importe sur quoi est basé un UUID. Un UUID, c'est par définition un identifiant (hautement) unique. Les détails de l'implémentation sont dans le code (eclipse: F3) et sa spec dans les RFC. Tout ce qui t'importe est que c'est un truc standard unique facile à utiliser. Plus d'infos: https://fr.wikipedia.org/wiki/Universal_Unique_Identifier sam.
Le 25/02/2018 à 12:16, jp a écrit :
Oui si c'est comme ça d'accord...
Ah ben voilà!
Mais est-ce que que l'objet aléatoire
retourné est basé en partie sur la date pour éviter d'en avoir 2
identiques?
Peu importe sur quoi est basé un UUID. Un UUID, c'est par définition un
identifiant (hautement) unique. Les détails de l'implémentation sont
dans le code (eclipse: F3) et sa spec dans les RFC. Tout ce qui
t'importe est que c'est un truc standard unique facile à utiliser.
Plus d'infos:
https://fr.wikipedia.org/wiki/Universal_Unique_Identifier
Mais est-ce que que l'objet aléatoire retourné est basé en partie sur la date pour éviter d'en avoir 2 identiques?
Peu importe sur quoi est basé un UUID. Un UUID, c'est par définition un identifiant (hautement) unique. Les détails de l'implémentation sont dans le code (eclipse: F3) et sa spec dans les RFC. Tout ce qui t'importe est que c'est un truc standard unique facile à utiliser. Plus d'infos: https://fr.wikipedia.org/wiki/Universal_Unique_Identifier sam.
