Discussion :

[MrDuChnok]

Bonjour,

Je suis en train d'utiliser les JTables dans le cadre d'un de mes projets, et je suis donc amené à utiliser les TableModels.
J'ai voulu créer mon propre TableModel en surchargeant AbstractTableModel pour qu'il n'accepte des objects que d'un type donné.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public class monTableModel<T extends Object> extends AbstractTableModel

Tout se passe bien jusqu'au moment de la méthode : setValueAt.
Je pensais que écrire ceci suffirait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public void setValueAt(T value, int row, int col);

Mais là, il me sort :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Name clash: The method setValueAt(T, int, int) of type monTableModel<T> has the same erasure as setValueAt(Object, int, int) of type AbstractTableModel but does not override it

Si je change le prototype de ma méthode, en remplaçant "T" par Object, ça fonctionne, mais bien sûr je perd un peu le coté "spécialisation" de mon TableModel.

Comment puis-je faire pour résoudre ce problème ? C'est à dire pouvoir "spécialisé" ma méthode setValueAt.

Merci.

[®om]

C'est normal dans la classe parente (AbstractTableModel / ou interface TableModel), la méthode est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

setValueAt(Object,int,int)

Tu n'as pas le droit de changer les types des paramètres lors d'une surcharge.

Le problème ici c'est que TableModel n'est pas générique, il aurait fallu qu'il soit générique à la base pour que tu puisses faire ce que tu veux faire... étendre AbstractTableModel<T>...

Au passage ton "extends Object" ne sert à rien

[adiGuba]

Salut,


Ce n'est pas possible car le type T pourrait être différent de Object et donc potentiellement incompatible avec la définition de la méthode setValueAt() (même si dans ce cas précis cela pourrait fonctionner).

Le plus simple serait de te créer une nouvelle méthode en remplacement de setValueAt(), par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
	public void setTypedValueAt(T aValue, int rowIndex, int columnIndex) {
		// ton code ici
	}

Et dans setValueAt(), tu te contentes d'appeler cette nouvelle méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	/**
         * @throws ClassCastException
         */
	@SuppressWarnings("unchecked") // cast (T)
	public final void setValueAt(Object aValue, int rowIndex, int columnIndex) {
		this.setTypedValueAt((T)aValue, rowIndex, columnIndex);
	}

Tu peux mettre la méthode en final pour qu'elle ne soit plus redéfinie directement...



Pour la méthode getValueAt() tu ne devrais pas avoir de problème car la covariance des types de retour te permet de modifier le type de retour dans certains cas : (tu as de la chance car le tutoriel est publié aujourd'hui même : La covariance des types retournés par les méthodes en Java 5).

a++

[MrDuChnok]

Merci bien de vos explications claire et net. Ca rejoint l'idée que j'avais.

Au passage ton "extends Object" ne sert à rien

C'est ce que je pensais, mais par desespoir, je m'étais dit "on sait jamais, sur un malentendu..." ^^'

J'avais opté pour ta solution adiGuba, mais ça laisse une petite "faille" si on passe un objet différent de T dans la méthode "setValueAt", c'était ça qui me dérangeais.

Merci quand même d'avoir pris le temps et répondre et d'argumenter vos réponses.

[CyberChouan]

J'avais opté pour ta solution adiGuba, mais ça laisse une petite "faille" si on passe un objet différent de T dans la méthode "setValueAt", c'était ça qui me dérangeais.

Dans ce cas, tu peux vérifier le type de l'objet dans un test, et agir en fonction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if(tonObjet instanceof T) { /* ok */ } else { /* pas ok */ }

[®om]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if(tonObjet instanceof T) { /* ok */ } else { /* pas ok */ }

Non, tu n'as pas le droit au "instanceof T"...
instanceof n'intervient qu'à l'exécution, le T n'est dispo qu'à la compilation...

[CyberChouan]

Non, tu n'as pas le droit au "instanceof T"...
instanceof n'intervient qu'à l'exécution, le T n'est dispo qu'à la compilation...

Argh! Zut! Merci pour cette précision, je ne savais pas (C'est ça de travailler tous les jours sur du java 1.4. J'essaye de me tenir au courant des nouveautés mais je ne pratique pas assez le 5.0+ pour bien connaître )