Reprise du message précédent :

 
Bien entendu

moi je fais comme ça:

vois pas pq? c'est dans la signature de la methode, pourquoi le dupliquer dans la doc (si ça n'apporte pas plus d'info) ?

-- > ah oui merde ça doit être ça le truc exact de la faq en plus (j'évite de trop surfer parce que je suis en 56k)
 
le @throws doit documenter les conditions dans lesquelles la méthode va pêter, ce qui est à mon sens très rarement immédiat.

ben oui si t'ajoutes de l'info pertinente, mais t'avais l'air de faire un lien entre le testcase et le fait de mettre @throws ProuteException dans la doc, alors que ça n'a aucun lien ni aucun interet si on ajoute pas les "conditions dans lesquelles la méthode va pêter" justement
 
 
 
(hahaha, ProuteException, la methode qui va peter, ahhaha)

http://jakarta.apache.org/commons/ [...] index.html
putain mais pourquoi ces gens se sentent toujours obliger de foutre des milliards de méthodes statiques partout au lieu de faire une api simple et propre? résultat, le truc est inutilisable sans lire de docs ou de sources

ouh yeah, jira qui se fait spammer: http://membres.lycos.fr/gggrrrreeeggg/shots/shot_4.png

Sans doute parce que la plus value d'instancier un objet "encodeur base64" est faible.

oui, en effet, je viens de voir les sources; et les methodes d'instances deleguent aux methodes statiques. toujours est-il que c'est un sacré bordel ce truc.

dites, savez si un String... (varargs) peut etre utilisé comme clé d'une HashMap sans danger?

 
 
j'en ai besoin aussi, et je comprends pas le coup du pattern...
 
Ca marche pas si on stocke direct un new String(digest)?

ben le byte[] renvoyé par MessageDigest c'est pas des caracteres lisibles. donc stuveux pas etre emmerdé par ta db (j'ai pas l'impression que ce soit hyper trivial de faire de l'unicode avec les bases de données, déjà les encodings + simple c parfois galère...), tu encodes en hexa ou en base64. et si tu veux pas te faire chier tu prend commons-codec, la classe DigestUtils fait tout ce dont tu as besoin à mon avis. (sinon tu mattes les sources)

je pense pas : le varargs c'est un bête tableau ... et je crois pas que equals et hashcode soient implémentée de la façon dont tu le souhaiterais

ouais, c'est ce que je craignais. grmf.

(remarque jpourrais betement coller mes String ^pour faire ma clé)

ou bien tu fais une encapsulation de ton tableau dans un object juste pour coder correctement les hashcode et equals

oué en effet.
un truc con genre une addition des clés ça suffirait ?

remarque, je me demande si en faite ca marche pas correctement : http://java.sun.com/j2se/1.5.0/doc [...] ng.Object) ... le hashcode est même caché ...
 
 
edit : merde, google m'a trompé, c'est pas le bon package  

mais euh, tu regarde la doc des packages jmx là

t'as tout ce qu'il faut dans java.util.Arrays
 
edit : enfin, depuis le java 1.5

ha oué. since 1.5
>ben oué, mais si jte parle de varargs c'est que chuis en 1.5 tfaçons

ouais, j'ai vu

j'ai vu que t'avais vu

mais heu  
j'édite pas assez vite
 
edit : pas con pour le varargs  

(l'Arrays.equals etait là avant 1.5 apparement)
 
bref, merci

sinon, pour le < 1.5, y a de quoi dans ArrayUtils de commons-lang chez jakarta

oué j'imagine.

je réponds à la bourre, mais plus précisément :
http://java.sun.com/docs/books/jls [...] html#64347
 
il est clair que hashCode() et equals() sont ceux de Object. Et il n'y a aucune raison de partager les instances entre appels. donc non.
 
D'autre part, tu as probablement intérêt à mettre en cache le hashcode dans l'objet qui te servira à wrapper ton tableau, sinon tu fais monter significativement la complexité.

ben l'truc c'est que j'aurai jamais la meme instance de mon "String..." qui va m'etre repassée, à priori. A moins que le compilo soit assez malin pour m'en faire un static
(parce qu'a priori je vais appeler une certains methode truc("foo", "bar", "baz" );

ouioui, c'est mon argument.

que?

si je me trompe pas, le hascode est utilisé également pour les instance des clefs déjà présentes pour optimiser le test d'égalité (teste d'abord l'égalité du hashcode, puis si c'est égale, teste le equals) => c'est important de cacher le hashcode des objets qui vont être stockés comme clef de la map.

mais oui mais ce que je dis c'est que ça sera pas - à moins d'une optim de compilo faite à mon insu - la meme instance qui va me servir de clé pour stocker et recuperer mes valeurs, donc je vois pas ou/comment cacher le hashcode "dans" cette instance va aider à quoi que ce soit, dans ce cas précis.

nan, effectivement ... comme je le disais c'est uniquement intéressant de cacher les hascodes des clefs sauvegardées dans la map.

tu peux forcer les intern() si tu sens que ça vaut le coup.
 
 
mais je te parle surtout des trucs qui sont dans la hashmap, au moment de parcourir la partie liste chaînée ça peut jouer d'avoir un cache.

ha ça y est j'ai compris

j'ai encore une question merdique tiens. jsuis en train d'essayer de reproduire un bug merdique, et pour ce faire, je lance 500 threads; je garde une reference sur les Runnable que je leur passe en argument, pour pouvoir recuperer un truc et comparer, voir si tout c'est bien passé.
bon, y'a un moment simple de betement attendre que tous ces chers Threads aient fini leur bousin dans run() ?
(paske le Thread.sleep(x) est un peu hasardeux )

join() non?

un compteur et un wait().
 
le compteur est à 500. chaque thread qui fini le décrémente (dans un bloc synchro) celui qui le passe à 0 débloque le surveillant.

500 threads en parallèle ça commence à faire vraiment beaucoup.

 
nraynaud-> merci