Reprise du message précédent :
ben getClass().isAssignableFrom() nan ?
enfin bref, oui, c'est pas tres cool y'a surement une api de chez google pour remplacer ça

non, parce que le Type ça peut être un ParameterizedType et donc les règles pour isAssignableFrom() ne portent plus sur l'erasure, mais bien sur le type générique, comme à la compilation.

A qui ressemblez-vous ?

60% à Pete Sampras et 52% à Ken Thompson et 47% à Kevin Mitnick

 
Si t'as besoin, je crois que je l'ai déjà codé quelque part, c'est assez chiant à coder/tester d'ailleurs...

pour l'instant je garde en dur, si je dois commencer à généraliser l'appli, je le ferai.

IntelliJ 9M1

Quand tu joues avec un projet un peu trop gros et qu'une opération est en train de buter l'IDE (parce que GC qui tourne en permanence parce que Xmx trop bas) il te demande si tu veux qu'IJ édite son Xmx et se relance
 

  j'en ai marre d'Eclipse

J'l'ai lancé, 5mn plus tard IJ était en cours de téléchargement

Bon, histoire que ce soit pas à chaque fois moinmoin qui les lance, j'voudrais un vrai débat File.exists vs FileNotFound

--, nray, lâchez vous, je colle ça dans le topic des noobs derrière

tu viens de voir ça? http://misko.hevery.com/2009/09/16 [...] ave-to-go/
parce que j'ai été tenté de le relancer sur le coup ..

Non, ça je l'ai vu il y a 10 jours (j'ai son blog dans reader), là c'est juste comme ça tac tac

y'a pas de débat, y'en a un qui a un race condition et pas l'autre, c'est tout.

 
Chais plus si j'en avais parlé ici :

Bien ? Pas-Bien ?

on notera tout de même que la race condition pourrait aussi avoir lieu ("ohhhhh le fichier est revenuuuuu" ) pendant l'execution du catch block ...

non.  
 
en soit tu veux écrire dans le fichier et donc tu le créés et ouvre en une opération atomique, soit tu veux uniquement le lire et l'ouverture va foirer.

Question Stripes + JBoss

J'ai un ActionBean classique :

public class FooBean extends ActionBean {
 
    @EJBBean
    public BarManager barManager;
}

Avec sur le serveur :

@Local
public interface BarManagerLocal {}

et

@Stateless
public class BarManager implements BarManagerLocal {}

Et là je mange un "Unable to find an EJBBean with name [barManager] in the initial context." Alors qu'il y est, hein. Pas grave, je vois dans la doc de stripes-ejb3 que si un cas semblable se produit, il y a une bidouille, à savoir (j'ai également tenté la version manuelle "@EJBBean("barManager" )", même chose) :

@Stateless
@Local(BarManagerLocal.class)
@LocalBinding(jndiBinding = "barManager" )
public class BarManager implements BarManagerLocal {}

Mais dans ce cas, bim la claque "Can not set BarManager field barManager to $Proxy215"

Je comprend bien que je ne lui file pas ce qu'il attend, mais alors quoi ?

Edit : topic dédié => http://forum.hardware.fr/hfr/Progr [...] 5496_1.htm
mais je sais que l'élite ne sors pas d'ici

quelqu'un a déjà utilisé XStream pour lire un certain format de fichier et en écrire un autre ?
 
En gros j'ai renommé un attribut dans mon format de fichier, je voudrais toujours être capable de lire l'ancien format mais toujours écrire le nouveau. J'arrive pas à bidouiller avec les converters.

bon une question un peu plus facile : y'a des concurrents à EqualsBuilder et HashCodeBuilder de apache commons ?

SOS la réflexion avec les enums

types primitifs

Impossible d'utiliser les google collections pour tranformer un String en autre chose (via toCharArray)

Langage de merde

bon, j'ai un soucis un peu con, et très 1997 dans l'esprit.
 
J'ai une applet (lol), qui ne tourne que sur windows, et qui utilise une dll par JNI.  
L'applet est signée, la dll chargée par System.load(...), tout va bien et tout le monde est content.
 
On copie l'applet sur un autre serveur, et on passe un coup sur l'un, un coup sur l'autre, sans forcément fermer le navigateur (IE6, relol)
La dll est présente sur le système client, et donc commune aux deux appels.
 
Les deux instances de l'applet, ayant un codebase différent, sont chargés par deux classloaders différents.
Par conséquent, quand la deuxieme fait son System.load(...), ca pête.
 
Faire une copie temporaire de la dll avant le load "corrige" le problème, mais c'est laid.  
Y'a t'il une autre solution ?

et si la 2e fait pas le load, elle peut pas utiliser la lib? (i.e. si la lib est partagée bah euh tu checkes, quoi, mais je suppose que c'est isolé...)

Apparemment, non. Je n'ai pas vérifié par moi même par contre, donc peut-être que le mec qui m'a remonté le problème a mal testé. Je dois vérifier.

je confirme que c'est bien isolé, si le 2 load() échoue, que je l'ignore et que je continue, je me prends un java.lang.UnsatisfiedLinkError lors de l'appel de ma méthode native.

http://bugs.sun.com/bugdatabase/vi [...] id=4642062

la dll en question c'est un truc custom? à ce moment, au point ou vous en êtes, vous pourriez ptet aussi faire ça? (bouger le System.load() dans un jar maison, que les clients devront coller dans JRE/lib/ext)

ouais, la dll c'est du code a nous. Le soucis, ca va être la diffusion, notre parc est mal branlé, on ne sais même pas toutes les versions de jre qu'on a... Copier la dll avant le load sera plus simple.
 
Merci d'avoir trouvé le bug chez sun en tout cas

System.out.println(System.getProperty("java.ext.dirs" ));
(si t'es motivé, doit y'avoir moyen de basarder l'install dans ton soft .. sauf que l'applet pourra sans doute pas aller écrire la dedans )

Une applet qui ne fonctionne que sous Windows, à utiliser dans IE6? Ca doit être chouette l'ambiance au boulot. Si ça pète trop, tu peux toujours essayer de le faire en ActiveX

salut les gars,
 
j'ai un glassfish qui tourne sous JDK1.5.0_06 et je voudrais un heap dump...
je ne peux pas arrêter, flagger, tripoter et redémarrer le server car on voudrait un heap d'un souci qui est présent pour l'instant.
 
sous visualvm, le boutonniau "Heap Dump" est grisé puisque, je suppose, la JVM n'est pas capable de dumper (JVM Capabilities> Heap dump supporoted: no)
 
commenkonfé pour flagger à yes ce truc ?!? (tant pis si il faut rebooter la JVM, on est bloqué tant que l'on ne peut pas dumper)

faudrait savoir
 
c'est quoi l'os ?

paske je voudrais essayer sans
(j'ai même crapahuté dans la JMX pour tenter de trouver une opération à exécuter...)
 

win 2003 server ( )

enfin j'allais dire: kill -3
cygwin, ptetre ?

(bon ben apparement chuis pas le premier à chercher : http://www.google.com/search?q=java+kill+3+windows )

Une lib java qui permette de faire du Null Object Pattern, qui à ça en stock ? C'est pour une lib de test où typiquement on a une tonne de getTruc().getMachin().getBidule() à faire avec getTruc() et getMachin() à 3/4 du temps à null (et ça fait chier de rajouter des if partout)
 
 
(cross post avec expert@prog pas si expert)

easymock, mockito, ...
sinon l'impl NullObject de tes interfaces, tu les écris toi meme, feignasse

en utilisant les mocks partiels de mockito, ça ne marche pas : on ne peut pas faire un "spy" sur un objet en lui mettant comme settings de retourner des mocks partiels sur tous les getters.
 

  si j'ai besoin d'une lib qui le fait, c'est pour ne pas le faire.
 
 

I DOESN'T WORK THAT WAY///
 
En plus ce que tu demandes là c'est pas vraiment du null-object pattern (dans son acception la plus classique), c'est du null-passthrough, identique au comportement de nil en Obj-C

google me fourni pas de lib qui font ça en java.
 
Si il faut le faire soit même, c'est quoi le bon point de départ niveau outils mise à dispo ?

PAINT ME SURPRISED
 
NOT