Reprise du message précédent :
ceci dit, vu comme c important comme JSR, si on lui a confié c'est qu'elle doit toucher méchamment....

et jubi qui en remet une couche dans le gravleux ...

le pire que ct même pas voulu...
 
APPLI DE MERDE PUTAIN :  
note pour plus tard : pisser à la raie du chef de projet qui me demandera de reprendre du code fait sous jbuilder par un type qui a pas réfléchit plus de 2sec à ce qu'il faisait...c magnifique : g fait un thread, qui marche très bien qd je l'appel d'une GUI bidon, sans me bloquer la GUI (c un peu le but du thread)...
 
si je l'appel de l'appli, ca me freeze la GUI

oué, j'avais tenté de reprendre JChatIRC niveau interface, mais face au bordel dans les threads, j'ai laissé tomber, je cris que le nom respect de la règle du thread unique en swing, c'est vraiment un des trucs les plus difficile à rattraper.

On utilisera çui de Yaou, qui paraît-il le concurrence méchamment depuis peu (en terme de validité de recherche ET de rapidité)

http://tockit.sourceforge.net/docco/

Question rapport aux transient en j2ee...
"Normalement", déclarer un attribut d'un SessionBean devrait suffir à ce que celui-ci ne soit pas sérializé avec ce sb..
 
J'ai comme un doute à ce sujet, et il paraitrait que monsieur Raynaud aurait qques précisions à apporter à ce sujet... Je vous écoute

 
Yahoo utilisait le moteur de google avant non ??
 
c pas juste une grosse repompe le leur ?

ouaip, j'ai lu dans un bouquin que quand le bean sort de son dodo, les champs transients ne sont pas remis à leur valeur par défaut mais laissés à des valeurs bidon (les valeus qui trainaient là la fois précédente qu'on a utilisé l'instance quoi).
 
Et j'ai même compris pourquoi depuis.

 
là, je suis curieux

et pourquoi, donc?

 
comme c'est no limit sur les effets de bord de la fonction et qu'elle est sensée être exécutée sur des *nouvelles* instances il peut y avoir des effets de bord incompatibles avec des instances existantes.
 
D'autre part, il est impossible d'exécuter ce code sans appeller réellement le constructeur. Or les EJB sont entièrement prévu pour être exécutés par réflexivité et du 100% pure java sans réécrire les classes.

bon, je vais voir le mot reflexivite, et je reviens....
merci.

uriel> va trop loin, c'est à la page précédente.

 
la partie sur l'introspection? ca je connaissais, de suite, j'ai pas le temps mais je vais regarder un peu plus tard

certes, mais quand mon transient est a null par defaut (lazy instanciation), ça me broute un peu le mou.

pas de bol hein ?
 
y'a une callback faite exprès pour remettre ton truc à null.

ben ui, mais du coup la lazy instanciation perd de son interet piske mon bordel transient est utilisé par toutes les methodes du session bean

tu mets ton instance en pas transient.

si je tente d'affecter un champ privé par réflection depuis une inner class, ça va foirer non ? ça me fait chier d'aller chercher les accesseurs synthétisés.

ptetre, mais tu peux changer les accès  

oui, mais c'est mal et je vais mal dormir après.
 
bon, je vais peut-être faire des vrais javabeans en fait.

Je comprends rien, mais ca a l'air génial la "lazy bidulle"...

heu c'est rien l'instanciation fainéante :
 

 
ça permet d'amortir un peu le pic de consomation de mémoire au démarrage.

si g suivi, t'instancie qd t'a besoin, et pas systématiquement à la création...
 
c marrant la corps de ta méthode ressemble à celui du singleton...(je v me faire écharper )

non, elle ressemble au "singleton à instanciation fainéante".

oui c logique en fait...mais g toujours vu les exemples de singletons avec une instanciation fainéante...
 
--> c vraiment impactant sur les perfs ??? ca revient pas au même de threader l'init de l'appli pour créer les objets en parallèle ?

ça peut changer pas mal le temps de démarrage oui.  
Dans d'autres cas, ça peut diminuer la consomation mémoire.

c verbeux qd même comme procédé...

Surtout que ça oblige à rajouter une méthode get par constructeur différent

éh oh je si vous voulez pas l'utiliser, vous le faites pas hein. Par contre, vous plaignez pas après si c'est lent et que ça l'aurait moins été avec ça.

Mais je comprend pas. En quoi c'est plus économique. Pourquoi ne pas simplement instancier l'objet quand on en a besoin ?

Mais justement ! on l'instancie quand on en a besoin, pas avant !

 
Vachement important les constructeurs différents sur un singleton

 
Ben oui. qu'est ce qu'il y a de différent si je garxe ma référence à null en attendant, et fait un appel au constructeur quand j'en ai besoin uniquement !?

l'instanciation ne se fait pas pendant que tout le monde tire comme un boeuf sur le GC.
 
Il y a une autre feinte mais que pas grand'monde n'utilise en java : on peut représenter des concepts infini sans exploser la mémoire.

ben c'est exactement ce que ça fait
sauf que c'est encapsulé et que tu dois pas répliquer la logique à tous les endroits ou t'as besoin de cet objet

Question bête !
 
J'ai une static nested class déclarée protected. Je cale au niveau du contructeur de la nested class. Je me demande le sens de public, protected, "" et private sur la décl du constructeur.

j'ai pas trouvé mieux que ça dans le JLS :

et j'ai la flemme de chercher plus.

ça fait chier, parce que je comprends pas ce que ça veut dire.

heu un type nested est un member. Mais ça ne répond pas à ta question sur le constructeur du type membre.