Comment déterminer si un .class est un nombre ?

Bonjour,

Dans l'une des classes de l'application sur laquelle je travaille actuellement j'ai un attribut de type Class.

Le truc c'st que j'aimerai savoir de manière générique comment faire pour savoir si le .class renseigné correspond à un nombre.

Quand on utilise des Nombres objets ( Integer, Long, ....) un simple

Code:

---

1 2 3 4 5 6 7 8

Class var; /*  on rempli var par exemple : */ var = java.lang.Float.class; Number.class.isAssignableFrom(var)

---

rempli très bien son boutot.

Le problème c'est que ce ne sont pas forcément des objets Nombres qui sont utilisés mais parfois des types primitifs comme "float.class", "long.class" et dans ce cas là le test précédent

Code:

---

1 2 3 4 5 6 7 8

Class var; /*  on rempli var par exemple : */ var = float.class; Number.class.isAssignableFrom(var)

---

échoue (normal)

Pour le moment, en guise de gros truc pas beau mais qui marche je fais un test sur tous les types de nombre de java ( long, short, double, ...) oui je sais c'est très moche, j'en suis parfait conscient mais comme je ne vois pas d'autre moyens je fais comme ça :'(

Salut,

Je ne pense pas qu'il y ai d'autre solution que de comparer avec les class des différents types primaires...

a++

Peut-être en rusant avec l'auto-boxing de J2SE 5.0.

Code:

---

Object.class.isAssignableFrom(var)

---

Si ça renvoit false, c'est que c'est un type primitif.
Reste à tester si c'est pas un boolean dans ce cas et c'est terminé.

Citation:

---

Envoyé par Satch

Code:

---

Object.class.isAssignableFrom(var)

---

Si ça renvoit false, c'est que c'est un type primitif.
Reste à tester si c'est pas un boolean dans ce cas et c'est terminé.

---

Dans le même genre, il y a en plus simple la méthode isPrimitive() de la class Class. Renvoie true si l'objet Class est de type primitif.
Il reste plus qu'à tester si c'est un booléen comme disait Satch.

@++

Citation:

---

Envoyé par Gfx

Peut-être en rusant avec l'auto-boxing de J2SE 5.0.

---

De plus, je suis d'accord avec Gfx, surement qu'en utilisant la version 5.0 du JDK, le compilateur devrait vérifier ça tout seul avec l'autoBoxing.
Avec kelle version tu compile ???

en fait je suis en 1.4 donc j'ai pas cherché du coté de l'autoboxing.

sinon pour les types primitifs ben je vais faire bourrin .... un test par type ( short, int, long, double, float)

car sinon ça m'inpose de chercher si c'est un type primitif et si c'est un type primitif alors si ce n'est pas un "byte", un "char", un "boolean" donc en terme du nombre de test ça va etre presque équivalent ( le test pour savoir si ce n'est pas un booléen n'est pas suffisant, il n'y a pas que les nombres et les booléen comme type primitif)

En tout cas merci à tout le monde ( ceux qui ont répondu et ceux qui ont cherché ;) ). Ca fait plaisir de voir que la communauté de ce forum est toujours aussi présente pour aider les autres ;)

Citation:

---

Envoyé par kisame

il n'y a pas que les nombres et les booléen comme type primitif)

---

Ha bon ? y a quoi d'autre ?

entiers : byte, char, short, int, long
decimaux : float, double.
boolean : boolean

A part le boolean tous représentent des nombres.

Citation:

---

Envoyé par Satch

A part le boolean tous représentent des nombres.

---

char représente un charactère, et la classe Character n'hérite pas de Number...

Par contre tu as raison il vaut mieux se concentrer sur les type primitif qui ne sont pas des "Number" car il y en a moins :

Code:

---

1 2 3 4 5 6

public static boolean isNumberAssignable(Class c) { if (c.isPrimitive()) { return ! ( c.equals(boolean.class) || c.equals(char.class) ); } return Number.class.isAssignableFrom(c); }

---

a++

et bien merci pour ces précisions adiGuba et satch
( je m'en vais faire un gros copier-coller de ta méthode ). Pour les byte je me suis trompé mais sinon pour les char, la distinction en char et nombre est faite sciement. Suivant que c'st un nombre ou pas j'utilise un renderer différent ( chose que je n'avais pas précisé)

et je pense que pour un utilisateur lambda, un char est plutot perçu comme un string avec un 1 caractère. Et personnellement aussi je pense qu'une représentation numérique possible d'un char n'en fait pas pour autant un nombre. Sinon il n'y aurait pas eu de disctinction de type ( c'est de l'abstraction peut etre superflue mais dans mes applis quand je demande à l'utilisateur de choisir 'y' ou 'n', dans mon code je ne fais pas le test sur la valeur en ascii de ces lettres), mais ceci est un autre débat :lol:

en tout cas re-merci à tout le monde.