Reprise du message précédent :
heu un type nested est un member. Mais ça ne répond pas à ta question sur le constructeur du type membre.

C'est pas primordial de toutes façons.

bah rien a part le (2)

enfin le (3) ça depend comme il faut l'interpreter

perso, j'avais même pas compris la question. Ensuite, il est hors de question que j'expose ce genre de comportement à n'importe qui en implémentant publiquement l'interface, je fais un truc nested qui aura accès à mes champs et je le donne à qui *je* veux. Comme ça les boulets ils peuvent pas faire n'importe quoi.
 
 
 
rien à voir (ou presque) mais je songe pas mal à ce truc en ce moment : on fait des espèces de méduses, un classe qui a de l'extérieur un comportement tout petit, mais qui va aller enregistrer ses petites classes nested (des Listeners, des Runnables, etc.) un peut partout dans le graphe d'objets.
ça fait un dos rond de l'extérieur (on voit juste un peu de trucs) et en-dessous, y'a des tentacules partout dans le graphe.
 
Et les boulets ne peuvent pas caster comme des porcs.

JE COMPREND RIEN >.<

je suis à 2 doigts de jouer avec ça : http://java.sun.com/docs/books/tut [...] index.html
 
vous avez une bonne raison pour que je le fasse pas ?

y'a un plugin d'xdoclet2 pour generer tout ce bordel
enfin je crois

je m'en fous, je parlais pas de ça.
 
Je parlais de mettre les 2 pieds dans cette techno morribonde et bouffeuse de mémoire.
 
 
edit : et qui file des gaz

ah oui :
http://xdoclet.sourceforge.net/xdo [...] -tags.html
 
ça s'utilise comment cette daube ? il va m'éditer le .java ?

xdoclet2 putain
cte vieille merde d'xdoclet 1
il *genere* triple crétin

http://docs.codehaus.org/display/XDOCLET/BeaninfoTags

c'est vrai que pour une spec qui a à peine 7 ans, il faut absolument prendre des trucs modernes.

bon, ça m'emmerde, je trouve pas de tuto.
 
Je vais faire mon bordel old-school et ça ira bien. de toutes façons, tout est fait par introspection.

euh http://java.sun.com/docs/books/tut [...] /beaninfo/ ?

Peut-être que si j'ai posté un lien du tuto javabeans, c'est que c'est le tuto d'autre chose que je cherche

ha oui

Darque > je t'ai vu sur un wiki ...

http://java.sun.com/j2se/1.4.2/doc [...] ditor.html
 
héhéhé, je comprends mieux pourquoi eclipse supporte pas les javabeans ...

-->je comprends pas... tt les éditeurs à part eclipse gèrent les javabeans...même JBuilder

Apparemment les classes fournies dans le package java.beans pour faciliter l'accès aux propriétés des beans sont liés à AWT. Comme eclipse est en SWT, ça le fait pas. Enfin c'est surtout que les devs d'eclipse auraient pu se bouger le cul pour ré-implémenter le tout en SWT, mais bon...

J'crois pas qu'IntelliJ gère les Beans non plus

genre ça : http://www.desnoix.com/guillaume/articles/lmf37/
 
?
 
chez moi c'est interdit.

euh non pas genre ça.

 
le 1 c possible je trouve  
le 2 aussi...mais alternativement...
 
après je sais pas...c vrai que c couillon, pis la réponse doit etre dans le kit de formation

Jubi > non, tu n'es pas "obligé" d'étendre Thread, par contre Runneable c'est obligatoire. Et Thread implémente Runneable.
 
D'ailleur cette dernière chose est très naze :

 
quand on vous dit qu'il faut aggréger et pas hériter, il y a des raisons (à leur décharge ce système date des années folles de l'héritage, avant les inner classes en plus) !

why ? on est pourtant exactement dans la situation de départ de la question.
 
 
 
 
Pour ceux qui se demanderaient, la bonne réponse pour moi c'est :

où les boulets peuvent se pointer avec leur Thread(), ils risquent pas de foutre la zone dans ma synchronisation.
 
Il faut bien voir que ce qu'on déclare comme interface est publique, c'est donc une invitation à l'utiliser. Là on a un composant et c'est tout. Pas une tache.
 
Pareil, dans la suite de l'article, pas question d'implémenter publiquement ActionListener, qu'il n'y ait pas un boulet qui n'aille m'abonner mon composant à son menu.

- j'ai pas lu le contexte d'utilisation du brol de l'article en question
- ta maniere, ouais, mais tu demarres le thread dans ton constructeur, ce qui est pas non plus necessairement ce qu'on veut

-- > c'est pas moi c'est lui, j'ai gardé le même comportement en planquant ce qui doit l'être.
 
 
effectivement, son truc devrait surveiller addNotify().

-->c quoi le pb avec la méthode thread safe pour invoquer un thread qui interragit avec Swing ?
 
--> l'énoncé dit : faut que le bout de code puisse vivre sa vie...que tu étendes thread ou implémente runnable, c pareil...dans un cas tu peux t'autolancer, dans l'autre tu te passes en runnable dans un appel à un thread...c souvent scolaire ces trucs...

heu le mec qui sous-classe Thread, il a pas exactement en tête l'idée que son run() va être exécuté par plein de threads en même temps, et surtout, par d'autres Threads que this.

ca me semble logique...c vrai que c con ces questions : c le but des qcm : faut etre 100% sur de la réponse

nraynaud > C'est une question de quelle certif que tu as sortis là?

programmeur java 2, le plus petit.

te mine pas..y'a un site qui a farm dans le nom, ou qqc...si tu t'entraines en faisant les tests blancs et en mattant les réponses, après c les doigts dans le nez..c tjs le même style de question qui revient...

 
tain ca a vachement changé depuis que je l'ai passé alors

moi franchement la question me parait un peu trop floue pour ne pas etre louche non ?
url?

ratai, c'est développeur.
http://fr.sun.com/formation/certifications/developer/
 
heu oui, j'ai pas donné la réponse, c'est bien 2 avec les arguments à la cons qui ont été donnés ici (pas thread parce que c'est pas obligatoire, les 3 autres sont des conneries).

ouais... enfin le (3) est vrai, si on considere que run() et le point de depart et de fin du thread. évidemment si par là ils voulaient dire qu'on pouvait pas appeler de methodes privées ou creer d'objets...