Zitat von javama

soll man den Vector Typesieren, oder kann man die Methode optimieren sodass man keine Warning mehr hat

Zur Typsicherheit ist es natürlich besser den Vector zu typisieren. Man erspart sich auch ein cast beim Lesen.

Mit der Annotation @SuppressWarnings("unchecked") kriegst Du das Warning weg.

Moin,

Zitat von j2se

Mit der Annotation @SuppressWarnings("unchecked") kriegst Du das Warning weg

also ich habe mir angewöhnt, Warnings nie zu ignorieren (ob mit SuppressWarnings, zu seicht eingestelltem Compiler oder wie auch immer).
Die Argumente von einigen Kollegen von mir ("ist ja NUR 'ne Warning") finde ich persönlich sehr ignorant!
Es gibt immer einen guten Grund für eine Warning; sie zu prüfen und dann zu beseitigen dauert doch meist nur ein paar Sekunden !

Als ich hier meine 6 Projekte übernommen habe, durfte ich jeweils so zwischen 3.000 und 5.000 Warnings entfernen (!!) - in durchschnittlich gut 50.000 Programmzeilen !

Gruß
Klaus

@TO
Natürlich bekommst du eine Warning weil ich den Code auch nur so aus dem Source-File kopiert habe ...
Nach dem compilen hast du sowieso nur noch den RAW-Type *Type-Ereasure* ... in diesem Fall kannst du die Warning wirklich vernachlässigen da es nach dem Compilen genau so in der Class steht wie jetzt im Source

*Wer kam eigentlich auf diese Idee Generics durch Type-Ereasure abwärtskompatibel zu machen ? Der gehört echt an die Wand.*

kann mir jemand erklären was ist der Unterschied zw.

Code java:

1 2 3 4 5 6

@Override     public Class<?> getColumnClass(int columnIndex) {         if(columnIndex == 4) { return Boolean.class; }           return super.getColumnClass(columnIndex);     }

und

Code java:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/*      * JTable uses this method to determine the default renderer/ editor for      * each cell. Hierdurch wird ("true"/"false")als checkBox dargestellt.      */     @SuppressWarnings("unchecked")     public Class getColumnClass(int c) {         try {             return getValueAt(0, c).getClass();         }         // Für den Fall, dass die Tabelle leer ist         catch (ArrayIndexOutOfBoundsException e) {             return Object.class;         }     }

Also die erste Methode kann ich nachvollziehen aber die zweite habe ich nicht verstanden besonders die 0 bei getValueAt(0, c) , warum eigentlich 0?

Was die Methodensignatur an sich angeht unterscheiden sich beide Methoden NACH dem Compilen nicht mehr ... beide haben dann folgende Signatur

Code java:

1	public Class getColumnClass(int)

Das passiert durch sog. Type-Ereasure um Generics-Klassen abwärtskompatibel zu halten *was eigentlich so nicht funktioniert da es Generics erst seit Java5.0 gibt ... und mit Java5.0 compilte Klassen eh nur mit mindestens Java5.0 ausgeführt werden ... von daher -> Schwachsinn*.

Ansonsten returnen die beiden Methoden Objekte vom Typ Class ... welche genau und warum ist eigentlich eher unwichtig.