Reprise du message précédent :
ok, merci je vais voir.

on utilise jasperreports ici aussi, on n'en est pas particulierement satisfait, mais on n'avait aucune envie de faire un truc custom, donc on fait avec

en plus y'a un plugin m2 de la balle  
(pareil, je l'ai peu utilisé, ya 3 ans, l'api etait toute pourrite, mais ça faisait ce qu'il fallait que ça fasse, donc hop)

OK, quelqu'un m'explique le problème.
 
Soit screens un HashSet<Screen>, et screen une instance de Screen.
 
Voici ce que m'affiche le debugger d'Eclipse, à un temps T de l'appli :

 
  ??

et en dehors du debugger ?

HashMap<Screen, String> map = new HashMap<Screen, String>();
map.put(screen, "OK" );
System.out.println("Resultat =" + map.containsKey(screen));

Normalement ça doit retourner true (HashSet.contains fait juste un return HashMap.containsKey)
Si c'est le cas = méfie toi d'eclipse
Si ce n'est pas le cas, y'a un problème

Nan mais à la base si je suis passé en debug c'est parce que le contains retournait false. Si j'affiche les trucs dans le programme j'obtiens exactement pareil.
 
Si je reconstruis un HashSet à partir de celui existant, le contains passe (sur le nouveau HashSet donc). Sur l'original, y a rien à faire, et quand je passe en débug sur le truc du JDK, je peux le voir essayer d'aller chercher la clé dans la HashMap qu'il y a derrière, et ne pas la trouver alors qu'elle y est (HashMap#indexFor, plus exactement, retourne 7 alors que mon screen est à l'indice 0).
 
À noter que le HashSet vient d'une désérialisation à la base, y a ptete un bug alacon dans Java dans ce cas précis car sinon je vois pas.
 
edit pour quand je reviendrai voir ce post : le problème c'est quand on modifie un élément de la collection (quelque chose susceptible de changer son hashCode) APRÈS avoir inséré l'élément dans ladite collection.

compare ton screen.getClass() et screens.iterator().next().getClass()
 
si ca se trouve, ta classe a bougé depuis la sérialisation d'origine.

stocker des objets sérialisés c'est pratique mais c'est parfois délicat... même idée que lorill à propos de la "version"

J'ai une petite question.
Je ne peux pas tester dans l'immédiat, il faudrait faire une page spéciale, relivrer etcetera ...

alors on a :

internet -> ip www de la boite -> serveur http (A) qui gere les virtuals hosts -> serveur http (B) -> serveur j2ee

Je souhaiterais savoir si l'ip obtenue grace à HttpServlet.getRemoteAddr() donnera l'adresse ip internet du client qui se connecte, ou si ça donnera l'adresse du serveur Http (A) qui gère le virtual host.
Si je pose la question c'est car là quand on regarde la trace du serveur http (B) on voit que les ips qui font les requettes sont des ips de reseau local, qui sont probablement celle du serveur HTTP qui gère les virtual host (A).

Quand j'accède avec ma machine depuis l'interieur du lan, je vois bien dans la trace l'adresse de ma machine, vu que j'accede directement au serveur B

Est-ce que quelqu'un utilise QT Jambi ici ?  
J'ai l'impression que ca interesse pas grand monde d'utilise QT + Java ...

ça dépend de comment A et B font leur job. (mod_jk, mod_proxy, mod_rewrite ou autre bidouillage)

 
j'ai jamais utilisé QT...c'est quoi l'avantage sur Swing (c'est une vrai question) ?

 
Principalement le fait que l'intégration soit native sur Windows (win32), MacosX (cocoa) et Linux (enfin si on utilise KDE)

Depuis quand QT c'est du natif sur windows et os x? C'est aussi natif que swing, ils recreent leur propres composants a leur sauce.
 
Si tu veux du "natif", regarde plutot du cote de SWT.

par contre si tu veux un truc qui marche ...

 
Utilise Swing

Ouais, et puis, tu vas sous windows et tu cherches a naviguer avec un JFileChooser dans un répertoire qui contient un gros zip...

effectivement, ce n'est toujours pas réglé en 1.6.0_11...
 
sur le bugtrack de Sun on peut y trouver un filter:  

 
mais je n'ai pas testé... et c'est diablement limitant quand ce n'est pas son propre code

Y'en a qui ont utilisé ou se sont déjà amusé à faire un isAssignableFrom() generic-aware ? (capable de dire si un objet respectant une déclaration de type générique A respectera toujours/parfois/jamais une autre déclaration de type générique B, avec éventuellement les conditions pour le "parfois" )

j'ai un peu de mal à comprendre la question, tu pourrais donner un peu de code stp ?

private static interface PFoo<E> {}
    private static interface PBar<F> {}
    private static interface PBaz<F> extends PFoo<F> {}
    private static interface PEgg<F> extends PFoo<PBar<F>> {}
 
    private static interface InstA extends PFoo<Float> {}
    private static interface InstB extends PFoo<Number> {}
    private static interface InstC extends PBaz<Float> {}
    private static interface InstD extends PFoo<PBar<Float>> {}
    private static interface InstE extends PEgg<Float> {}
 
    @Test
    public void testParameterizedSubtyping() {
        // On verifie que InstC est bien un sous-type de Pfoo<Float> (via PBaz<F> )
        assertTrue(Types.isAssignableFrom(InstA.class.getGenericInterfaces()[0], InstC.class));
    }
    
    @Test
    public void testParameterNonWidening() {
        // InstA est un PFoo<Float>, On verifie que InstA n'est pas un sous-type de PFoo<Number>
        assertFalse(Types.isAssignableFrom(InstB.class.getGenericInterfaces()[0], InstA.class));
    }
 
    @Test
    public void testDeepParameter() {
        // Un cas avec un peu d'indirection histoire d'être sûr...
        assertTrue(Types.isAssignableFrom(InstD.class.getGenericInterfaces()[0], InstE.class));
    }

Le sujet de la question c'est l'implé de la fonction Types.isAssignableFrom(destination, source).
J'en ai une incomplète (essentiellement le cas "parfois" qui fait défaut, quand une variable de type est encore ouverte), mais je me demandais si y'en avait des dispo et bien faites pour voir si j'ai raté un truc ou s'il faut vraiment faire du dispatch à grand coup d'instanceof vu le vide béant de l'interface java.lang.reflect.Type, ou encore si l'idée même est généralement stupide...

 
on a laissé tombé l'identification par ip ...
 
 
 
petite question, quelle technique utilisez vous pour retourner plus d'un paramètre suite à un appel de fonction ?

Modification de l'objet dans la méthode ?

 
ma question est pas "comment" le faire    
 

 
ok mais donc tu te prévois à l'avance des objets nuplets ?
 
par exemple pour récupérer un String, et Integer, on peut le retourner en tableau d'Object et faire des casts derrièe, mais je trouve ça peu propre.

y'a uriel qui cherche qqun pour l'aider sur du fortran stuveux                  

Un conteneur n-uple (generic et indexé), un objet dédié, ou je triture le problème pour enlever le besoin de retourner plus d'un paramètre.

Ou alors je le fais pas en java

object dédié pour ma part ou je tors autrement le problème car ramener un Object[] c'est moyen moins même avec de la doc propre.

Si tu tient vraiment à retourner et que tu veut éviter les casts dégueux, tu peut créer un objet générique du genre :

class Pair<H, T> {
    public final H head;
    public final T tail;
    public Pair(H head, T tail) {
        this.head = head;
        this.tail = tail;
    }
    public static <H, T> Pair<H, T> cons(H head, T tail) {
        return new Pair<H, T>(head, tail);
    }
    public <NT> Pair<Pair<H, T>, NT> cons(NT new_tail) {
        return new Pair<Pair<H, T>, NT>(this, new_tail);
    }
    public static void main(String[] args) {
        Pair.cons("foo", 42).cons(3.14f);
    }
}

Et tu retourne des Pair<Type1, Type2> que tu crée avec Pair.cons(objet1, objet2);
T'as pas la clarté sémantique d'un objet fait exprès, le type de retour peut être très long si tu en abuse, mais c'est plus safe qu'un Object[].
( Néamoins, je passerais 2min à faire un objet exprès dans ce cas, ça gagne à la relecture...)

class Pair<H, T> {
    public final H head;
    public final T tail;
    public Pair(H head, T tail) {
        this.head = head;
        this.tail = tail;
    }
    public static <H, T> Pair<H, T> cons(H head, T tail) {
        return new Pair<H, T>(head, tail);
    }
    public <NT> Pair<Pair<H, T>, NT> cons(NT new_tail) {
        return new Pair<Pair<H, T>, NT>(this, new_tail);
    }
    public static void main(String[] args) {
        Pair.cons("foo", 42).cons(3.14f);
    }
}

T'es pas obligé d'utiliser des linked lists non plus, tu te fais un pair et un triple, ça devrait suffir pour 90% des cas

disons que j'ai pas encore la joie d'être en java > 1.5
 
Creer un objet spécial pour la méthode ouais, mais ça fait créer une classe en plus, c'est pas hyper réjouissant.
 
A la rigueur c'est peut être le seul cas ou je verrais (juste moi ) un intérêt à faire une classe interne, afin d'avir le type déclaré conjointement à la méthode.
 
La limite de ça c'est si la méthode est l'implémentation d'une interface alors là ça coince car on pourra pas utiliser d'autre implémentation sans garder cette dépandance

 
J'ai fait qu'une paire et un assembleur de paires, spa ma faute si tu peut faire des listes (et des dag) avec

Un peu foutage de yeule quand même, pair + cons = linked list, c'est pas comme si c'était un secret

Donc t'es en java 1.5?

THIS
IS
JAVAAAA

Il y a déjà des classes de partout, une de plus ou de moins

Il serait où l'intérêt d'une classe interne exactement

Ne pas créer un fichier

pas la joie d'être en java >= 1.5

excuse mon manque de rigueur

oui, et éviter de s'éparpiller pour rien, et indiquer tant bien que mal que l'objet en question n'est pas censé être utilisé en dehors du cadre de l'appel à cette fonction, ni ne doit être réutilisable pour autre chose.

genre classe interne + constructeur et factory privée

spa grave hein, !(a>b)  => a=b était de toutes façons pas très rigoureux.

son impertinance était rigoureuse

C'est possible de lancer des tests maven en changeant la date de la JVM ? Ca serait pour faire passer une série de test sans que la date change - on serait toujours le 5 janvier 2009 par exemple - (car sinon les résultats changes avec le temps et il faut aussi avec le temps alimenté les données...)
 
Changer l'heure de la machine n'est pas envisageable. (car les tests sont lancés par Hudson)
 
 
De ce que j'ai vu, System.currentTimeMillis() se base sur le système et ne m'a pas l'air configurable. Je sais qu'il y a un paramètre pour changer de fuseau horaire, il y a peut être un paramètre pour la JVM pour changer d'heure/jour !
 
Merci
 

Tu crées un proxy pour les infos de temps, que tu injectes avec un backing Date ou Joda dans la prod mais que tu peux mocker/contrôler dans tes tests?

edit: apparement si tu passes par Joda t'as même des outils inclus pour manipuler les dates/times fournies: http://www.markhneedham.com/blog/2 [...] joda-time/

Il y a des new Date() un peu partout  
J'ai mis un proxy, mais il est utilisé que dans les méthodes où je suis passé derrière.

C'est bon à savoir