Reprise du message précédent :

C'est l'inverse. Comme indiqué dans la doc.

Lis la doc, c'est marqué dedans

à propos des jeux et java,
 
en 2eme année d'info à l'iut, on a des projes de groupe à realiser,  
 
nous on fait un bomberman en 2d, typé MVC, avec IA et Reseau pour le multi, mais ca a tendance à vite ramer,
 
Java n'est pas forcement fait pour les jeux, mais quelles sont ses limites ?
 
j'envisage d'essayer ( et je dis bien essayer) pour mon plaisir de coder un jeu melange de worms et de UT, donc du temps reel pk pas en reseaux ou le but est d'exploser tout le monde.
 
utopie ou realisable en java ? sans que ca rame bien sur

 
Yep, j'avais pas encore lu la doc .

vous avez cherche a savoir ou ca ramait ? blamer java si rapidement c'est un peu facile. De mon experience, ca vient souvent d'une UI est codee avec les pieds ou tout est fait dans le thread swing, ou d'une couche reseau mal concue.  

non non je crache pas dessus hein, je me demande juste

je defends pas java non plus, c'est peut etre pas la meilleure techno pour des jeux 3D et companie, mais ce serait interessant  pour vous d'auditer un peu votre code pour voir ou ca rame exactement. De mon experience, les interfaces graphiques qui rament en java ont souvent un point commun: meconnaissance de swing et operations lourdes effectuees dans le thread swing. Genre si vous faites des operations reseaux ou IA dans ce thread, oui ca va ramouiller mechament  
tu peux fournir les sources ? eventuellement, ouvre un topic dedie a ton projet, ca peut etre interessant pour plein de monde.

j'en parlerais au groupe, on filera ptet les sources a la fin du projet, une fois que ce sera rendu
 
on connait pas enormement swing, c'est vrai

je plussois Souk : il faut comprendre qu'en Java, tout ce qui concerne Swing tourne dans un thread dedie. Donc si t'as des opérations longues a faire (IO disque, réseau, IA) faut impérativement les faire dans des thread séparés. Sinon ton UI va ramer parce que tu empeches swing de se rafraîchir. T'as des méthodes pour synchroniser ces threads entre eux (swingworker par ex)
 
De ce que j'ai vu de ton code t'as tendance a tout faire dans ton code swing

Merci Masklin, j'ai corrigé mon warning grâce aux generics.
Par contre ça m'étonne qu'on ne l'ai pas encore vu en cours mais qu'on en ai besoin en TP

ben t'en as pas besoin, ça compile et ça marche très bien sans.
(au passage si qqun a une explication autre que "le prof est un manche" sur le coup du Vector, ça m'interesse, parce qu'ils font tous ça on dirait)

TPs/leçons créées pour du java 1.0/1.1 et jamais vraiment révisées depuis, puisque pas spécialement d'intérêt pédagogique fondamental à le faire, c'est pas comme si les écoles enseignant java existaient pour apprendre aux gens à coder correctement.

 
Non, ça compilait avec un warning si je n'utilisais pas les generics.

Donc ça compile et ça marche sans

tain mais meme moi () j'ai jamais bossé avec 1.1
 
(merde, je viens de faire l'addition, je sais pas si je peux dire depuis combien de temps je fais du java )

Salut tout le monde,
j'ai un problème pour trier des objets contenus dans un vecteur en fonction d'un int.
Le tri se fait bien, mais si par exemple au début j'ai 9 livres dans mon vecteur, à la fin j'aurai toujours 9 entrées dans mon vecteur, mais trois livres apparaissant plusieurs fois.
 

// Tri par séléction ordinaire
        Vector<Livre> vtmp = new Vector<Livre>();
 
        for (i=0;i<vlivre.size();i++)
        {
            int imin=i;
            for (int j=i+1;j<vlivre.size();j++)
            {
                if (vlivre.elementAt(imin).getReference()>vlivre.elementAt(j).getReference())
                {
                    imin=j;
                }
            }
                
            vtmp.addElement(vlivre.elementAt(i));
            vlivre.elementAt(i).setTitre(vlivre.elementAt(imin).getTitre());
            vlivre.elementAt(i).setReference(vlivre.elementAt(imin).getReference());
            vlivre.elementAt(imin).setTitre(vtmp.elementAt(vtmp.size()-1).getTitre());
            vlivre.elementAt(imin).setReference(vtmp.elementAt(vtmp.size()-1).getReference());
        }
        
        System.out.println("Réaffichage de l'ensemble trié selon la référence :" );
        System.out.println(vlivre);

// Tri par séléction ordinaire
        Vector<Livre> vtmp = new Vector<Livre>();
 
        for (i=0;i<vlivre.size();i++)
        {
            int imin=i;
            for (int j=i+1;j<vlivre.size();j++)
            {
                if (vlivre.elementAt(imin).getReference()>vlivre.elementAt(j).getReference())
                {
                    imin=j;
                }
            }
                
            vtmp.addElement(vlivre.elementAt(i));
            vlivre.elementAt(i).setTitre(vlivre.elementAt(imin).getTitre());
            vlivre.elementAt(i).setReference(vlivre.elementAt(imin).getReference());
            vlivre.elementAt(imin).setTitre(vtmp.elementAt(vtmp.size()-1).getTitre());
            vlivre.elementAt(imin).setReference(vtmp.elementAt(vtmp.size()-1).getReference());
        }
        
        System.out.println("Réaffichage de l'ensemble trié selon la référence :" );
        System.out.println(vlivre);

On peut savoir pourquoi tu utilises des vectors (sans passer par les méthodes rétrofittées de Collection en plus), et surtout pourquoi tu réimplémentes un tri alors que c'est inclus dans la lib

edit: et accessoirement,

vlivre.elementAt(i).setTitre(vlivre.elementAt(imin).getTitre());
            vlivre.elementAt(i).setReference(vlivre.elementAt(imin).getReference());
            vlivre.elementAt(imin).setTitre(vtmp.elementAt(vtmp.size()-1).getTitre());
            vlivre.elementAt(imin).setReference(vtmp.elementAt(vtmp.size()-1).getReference());

c'est un peu gerbant

J'implémente les vecteurs parce que c'est ce qui m'est demandé de faire et ce que j'ai vu en cours

Mais c'est complètement con

Bon, j'ai essayé de faire ça, mais sa me pète deux warnings ("unchecked call to compare" entre autre) et j'ai un NullPointerException lors de l'exécution.
 
J'ai essayé de faire ça, mais j'avoue que je m'embrouille pas mal :
 

Comparator c=null;
        c.compare(vlivre.elementAt(0).getReference(), vlivre.elementAt(1).getReference());
        TreeSet<Livre> t = new TreeSet<Livre>(c);

Pour comparer selon la référence, c'est bon, j'ai réussi en redéfinissant compareTo dans ma classe Livre, puis en faisant simplement :
 
Collections.sort(vlivre);
 
Par contre, je dois faire de même avec des strings maintenant, je dois une fois de plus redéfinir compareTo ?

Si tu dois trier ta collection de plusieurs manières différentes, tu devrais plutôt implémenter une série de Comparator et utiliser Collections#sort(List<T>, Comparator<T> )

Si tu dois juste comparer des strings entre eux, c'est built-in

Et quand tu dis implémenter une série de comparateur, c'est par exemple définir deux méthodes dans ma classe livre :
 
compareString(Livre livre)
compareRef(Livre livre)
 

 
Et ensuite par rapport aux collections je l'utilise comment ?

Non, c'est créer des classes implémentant java.util.Comparator, et je t'ai donné la méthode à utiliser quand tu as ton comparator.

 
Ok, merci

Bon, jvais paraître con, mais vu que se ne sera pas la première fois, je me lance.
 
J'ai ça :  
 

class Comparateur implements Comparator {
    
    public int compareString(T o1, T o2) {
        return compare((String)o1, (String)o2);
    }
    
    public int compareRef(T o1, T o2) {
        return compare((Integer)o1, (Integer)o2);
    }
}

 
Mais il aime pas du tout.
Ce que je ne comprend pas c'est qu'il ne veut pas implémenter la classe Comparator

Comparator doit etre une interface, ya des methodes definies à surcharger

ha ouais qd meme. en meme temps le message d'erreur dit clairement ce qui va pas hein.

J'avais trouvé l'exemple sur internet

class Comparateur implements Comparator {
    
    public int compareString(T o1, T o2) {
        return compare((String)o1, (String)o2);
    }
    
    public int compareRef(T o1, T o2) {
        return compare((Integer)o1, (Integer)o2);
    }
}

 
hum...
relis ton cours sur les interfaces : si tu implémentes une interface, tu dois au minimum implémenter tout ce qui est défini dans l'interface de l'Interface que tu implémentes, ici Comparator.
Un coup d'oeil sur la doc de Comparator montre qu'il y a 2 méthodes :  

int compare(T o1, T o2)
boolean equals(Object obj)

 
et c'est logique : un comparateur ça permet de trier des objets...pour trier des objets faut que tu puisses avoir une relation d'ordre (bidule est plus grand ou plus petit que truc, voire égal)
 
un Comparator ça marche comme ça : t'as des collections et méthodes de collections qui sont prévues pour les utiliser. Comme ils savent pas comment tu vas implémenter ton comparateur, ils parlent à "l'interface" Comparator ,donc la seule méthode appelée sera forcément int compare(T o1, T o2).
Si tu veux avoir des Comparateurs différents (tri sur int, etc...) il te faut implémenter autant de comparateur que tu as d'ordres différents, et passer le bon pour obtenir le tri désiré.
 
Dans ton cas, il te faut faire 2 Comparator : un StringComparator (inutile car par défaut les collections savent trier des String) et un IntComparator
 
après, selon ce que tu veux trier, tu appelles la méthode sorte et tu passes une instance du Comparator qui t'intéresse
 

Sauf qu'en fait il s'est mal exprimé, ce qu'il veut c'est trier sa collection de livres, une fois sur une propriété qui retourne un int (reference) et une fois sur une propriété qui retourne un string (title)

donc il lui faut 2 Comparator...
 
un qui compare sur le getTitle (celui là est facile, il suffit de retourner le résultat de la méthode compareTo de String, qui est déjà implémentée), et un qui compare sur le getReference (là encore, Integer implémente comparable, donc il suffit de retourner le résultat de la méthode compareTo)

int compare(T o1, T o2)
boolean equals(Object obj)

 
Merci pour l'explication.
 

 
Oui, c'est ça.
 
J'ai finalement réussi hier, je n'avais pas saisi le principe qu'il me fallait deux classes différentes pour faire ce que j'avais à faire.
 

class ComparateurTitre implements Comparator {
    
    public int compare(Object o1, Object o2) {
        String titre1 = ((Livre) o1).getTitre();
        String titre2 = ((Livre) o2).getTitre();
        
        return titre1.compareTo(titre2);
    }
    
    public boolean equals(Object obj) {
        if (obj == null || (this.getClass() != obj.getClass()))
            return false;
        else
            return true;
    }
}

 
J'ai juste deux warnings (unchecked conversion), que mon prof ne sait pas résoudre, donc j'en appelle à vous
 
TreeSet<Livre> t = new TreeSet<Livre>(comp);
TreeSet<Livre> u = new TreeSet<Livre>(compref);
 

Tu utilise des collections génériques, il te faut donc un comparateur générique au lieu d'un comparateur 1.4:

class TitleComparator implements Comparator<Livre> {
    public int compare(Livre l1, Livre l2) {
        // Gérer le cas où l1.getTitre() est nul, si la chose est possible
        return l1.getTitre().compareTo(l2.getTitre());
    }
        
    public boolean equals(Object obj) {
        return this == obj;
    }
}

class TitleComparator implements Comparator<Livre> {
    public int compare(Livre l1, Livre l2) {
        // Gérer le cas où l1.getTitre() est nul, si la chose est possible
        return l1.getTitre().compareTo(l2.getTitre());
    }
        
    public boolean equals(Object obj) {
        return this == obj;
    }
}

 
Ah oui, et donc le fait de lui préciser qu'on ne prendra que des livres m'évite de devoir caster tous mes objets pour les passer en livre ensuite.
Pas mal

Petit question,
on est en train de développer un éditeur de partitions musicales en Java avec Swing.
 
Pour l'instant, on a utilisé netbeans pour créer la/les fenêtres sans devoir toucher au code.
Mais on sait très bien qu'à un moment ou à un autre on devra mettre les mains dans le cambuit.
Vaut-il mieux qu'on ré écrive tout à la main, from scratch ou alors on continu avec netbeans ?

si c'est pour apprendre, re-ecris tout  
 
efin c'est ce que je ferais

le pb de swing c'est le positionnement....pour obtenir ce que tu veux, va falloir mettre les mains dans un gestionnaire de Layout...Et GridBagLayout, ça irite un poil au début...
 
le code de netbeans est pas trop dégueu, je serais vous j'y toucherais pas trop...au pire renommez via les tableaux de propriétés les variables pour éviter des label1, label2, etc...
 
après pour manipuler, tu fais des getters//setters sur les modèles des composants swing, et tu updates en jouant sur le SwingWorker et autres (pas trop mal expliqué ici : http://gfx.developpez.com/tutoriel [...] threading/ )

 
pour toi c'est évident, pour lui ça l'était pas, CQFD

public boolean equals(Object obj) {
        if (obj == null || (this.getClass() != obj.getClass()))
            return false;
        else
            return true;
    }

 
un truc tout con : c très moche et lourd comme écriture le return false else return true.
 
fais ça directement :  
 

public boolean equals(Object obj) {
        return  ! (obj == null || (this.getClass() != obj.getClass()));
    }

 
ensuite tu peux pas vraiment dire que 2 objets sont égaux si ils ont la meme classe...tu peux appeler hashcode() par ex, ou vérifier ce qui au sens de ton objet veut dire l'égalité (par ex la méthode equals de String considère 2 String égales si elles contiennent exactement les meme caractères)