Reprise du message précédent :
merde, j'aurai dû, ça m'aurait fait une excuse /o\
 
(j'ai mal typé ma variable)

marche :  

 
 
marche pas:

une petite question , la classe JFrame elle appelle automatiquement la methode paint ou pas?  
 
car quand je run une classe qui herite de JFrame dans netbeans, ma methode paint est pas effectuée , pourtant dans le bouquin devant moi il est ecris que Jframe appelle la methode paint...?
 
voila merci

Le compilateur se rend compte que l'on appelle la valeur d'une propriété sans l'affecter ou l'utiliser.  

j'avais compris  

oui, sauf qu'en swing c'est interdit de toucher à paint, surtout sur un JFrame alors que c'est JRootPane qui est la racine des composants.`
 
va faire un tour dans le tutorial swing pour voir comment on fait de la peinture.

Quelqu'un peut m'expliquer pourquoi FuturTask implémente à la fois Futur et Runnable ??
 
Je trouve que Executor.execute() avec un FutureTask fait méchament doublon avec ExecutorServices.submit() qui retourne un Futur en lui passant un Runnable
 
Ca créé des situations bizarres du coup : on utilise quel objet pour suivre l'execution d'une FuturTask qu'on a passé à ExecutorServices.submit() ? l'objet retournée par la méthode (de type Futur) ou le FuturTask qu'on a passé en paramètre ? (c'est pas le même, j'ai vérifié dans les sources )

l'objet retourné

ca doit marcher aussi avec le paramètre nan ?
 
enfin, je sais pas ... tu trouves pas ca un peu bencale toi ?

non, ça doit pas marcher avec le paramètre.
 
et non, le submit, lui, il sait pas que tu lui as passé un FutureTask, si ça se trouve, la classe a été écrite avant même que FutureTask n'existe. Donc c'est wrappé.

Ca d'accord, mais vu que le futurtask fonctionne sur un Executor en tant que Runnable, ca veut dire que les executeur n'ont pas besoin de savori que c'est un FuturTask => il fonctionne plus ou moins tout seul sur un simple appel à la méthode run().  
 
Donc si il fonctionne sur appel à la méthode run(); pourquoi il marcherait pas si on le passe à submit() ?
Je pense que dans ce cas tu te retrouve avec un Furur qui wrappe le FuturTask (en tant que Runnable) et que les 2 fonctionnent ... je trouve pas ca très propre ...
Enfin je vois pa sl'intérêt de l'objet Futur à partit du moment ou on dispose du FuturTask ...

j'ai pas regardé la hiérarchie et les responsabilité là, je me suis intéressé qu'à la "technique" . Quand j'ai du temps, je regarde et je te dis quoi.

oki

bordel de merde, j'ai encore oublié de redéfinir le hashCode() alors que j'ai trafiqué equals() et que je joue avec des HashSets

par habitude, j'attends pas d'avoir à l'utiliser : dès que je redéfinis equals, je me fais le hashcode direct ...

alt-n : generate equals() & hashcode()

-- >

benou > je t'invite à lire la doc d'Executor.

http://java.sun.com/j2se/1.5.0/doc [...] util.List)
 
Et je découvre ça maintenant

kad > 'faut arrêter de sortir le dimanche hein ...

bha c'est déjà fait
 
j'étais sensé y voir quoi ?

 
J'ai du trop boire

benou > Executor, c'est une interface abstraite pour qu'on puisse faire nos propres executors, qui vont executer des Runnable.
 
Future, c'est une interface pour du calcul asynchrone qui dit pas comment on va calculer.
 
FutureTask, c'est une spécialisation de Future pour que le calcul soit fait par un Runnable.
 
Bon, la vraie valeur ajoutée de FutureTask, c'est que c'est la première classe concrète implémentant Future avec le code par défaut.
Là où ça se complique, c'est que canceller un Runnable, c'est pas gagné, mais c'est FutureTask qui se démerde.

je trouver que FuturTask mélange vraiment trop les 2 usages ... c'est pas clair ...
 
je vois pas l'intérêt d'avoir le ExecutorServices.submit() si on a un FuturTask qui peux être utilisé plus généralement sur Executor.execute()

benou > ExecutorService, c'est un usage particulier de tout ça, une implémentation clef en main pour pas s'emmerder.
 
en interne, on peut supposer que le code de l'objet renvoyé par Executors.newFixedThreadPool() utilise des FutureTasks.
 
C'est une différence de granularité : du plus général (Future, Runnable, Executor) au particulier (Executors.newFixedThreadPool() )

heu ... ExecutorServices ca reste une interface ... assez générique de plus ... d'après ce que j'en comprend elle induit un traitement désynchronisé (=> possibilité d'annuler le traitement), ce qui n'est pas forcément le cas d'un Executor ...
 
La classe d'implémentation c'est par exemple ThreadPoolExecutor ou  ScheduledThreadPoolExecutor.
 
 
(trop fort   )

quand on voit de où vient java.util.concurency, on comprend la raison de l'existence de FuturTask : http://gee.cs.oswego.edu/dl/classe [...] esult.html
 
Par contre, je comprends toujours pas la raison de l'existence de ExecutorServices.submit() : Futur

bon, qqun à déjà fait joujou avec JTAPI ici ?

JTAPIN, l'api des putains
 

 
 
de loin et il y a longtemps, pour?

savoir si ça marche et si t'aurais des liens, tutos ou autres, que les specs longuissimes ou les documents d'intro vaguissimes de sun.
 
et savoir si y'aurait des alternatives ou des couches au dessus, parce que le truc qui date de 97, je le sens pas trop

si j'ai un proxy sur un attribut d'une classe, le proxy est serializé et je le retrouve de l'autre coté du tube ou y'a moyen de plutot serializer ce qu'il y a derriere le proxy ?

[quote=989007,3680,32,76518]si j'ai un proxy sur un attribut d'une classe, le proxy est serializé et je le retrouve de l'autre coté du tube ou y'a moyen de plutot serializer ce qu'il y a derriere le proxy ?[/quote]
writeObject()
 
readResolve()  
 
mais surtout :
writeReplace()
http://java.sun.com/j2se/1.3/docs/ [...] .doc5.html

j'ai lu que clone() c'était mal.
mais là, j'ai l'impression que j'en ai vraiment besoin.
Ça fait un moment maintenant que je bosse sur un soft de gestion d'emploi du temps et donc je gère des évnènements représentés sur une grille, et là j'en suis au moment fatidique du drag n drop.
 
Les objets représentés sont assez compliqués, et je dois faire des testes  pendant le drag pour qu'on sache directement si le truc est déplacable ici où là.
 
Pour l'instant, j'ai fait un faux clone avec pas tout pour tester, cad que je clone l'objet, je le déplace et fais les tests dessus. Si au moment du lâcher les tests disent non, je fais rien, sinon, il faudrait que l'objet qu'on a déplacé se subtitue vvoyez.
 
En fait, je vois pas comment me passer de clone là. Enfin, plus généralement, je vois pas comment s'en passer quand on fait des trucs à base d'undo (ah si... j'avais lu sur le truc du GOF qu'il faut que chaque commande soit réversible... ouais mais non, là non   ) pour sauvegarder l'objet.
 
(Ah oui, je veux me passer de clone parce que j'ai la flemme d'implémenter clone() tellement y'a de trucs dans mon objet...)
 
donc là :

• ma méthode est pas bonne je suis dans l'impasse ?
• pas d'autre choix que d'implémenter clone() ?
• il existe des libs qui inspectent des objets et peuvent les sauvegarder en mémoire (même si ça va à l'encontre de java, puiske les concepteurs ont pas prévu çà) ?
• je serialize ?

 
(pas ouvert de topic dédié, c'est assez spécifique à mon cas là)

justement, ouvre-en un

tiens, connaitriez une tache ant qui applique un patch sur un fichier ? (comme 'patch' en command line donc )

http://www.cenqua.com/clover/eg/an [...] Patch.html
 
???

ha merde ça existe dans ant de base en fait, j'avais jamais vu
http://ant.apache.org/manual/CoreTasks/patch.html
(ce qui correspond au code que t'as posté quoi)

c'était exactement le sens de mon post, un peu comme un panneau quoi

ok
http://forum.hardware.fr/hardwaref [...] 4973-1.htm