Entier.classe vs int.classe

Integer.class est, comme vous le dites, une référence à la Class objet de la Integer type.

int.class est, similarité, une référence à l'objet Class pour le type int. Vous avez raison de dire que cela ne semble pas correct; les primitives ont toutes un objet Class comme cas spécial. C'est utile pour la réflexion, si vous voulez faire la différence entre foo(Integer value) et foo(int value).

Integer.TYPE (pas Integer.type, vous l'esprit) est juste un raccourci pour int.class.

Vous pouvez avoir une idée de cela avec un simple programme:

public class IntClasses {
  public static void main(String[] args) {
    Class<Integer> a = int.class;
    Class<Integer> b = Integer.TYPE;
    Class<Integer> c = Integer.class;

    System.out.println(System.identityHashCode(a));
    System.out.println(System.identityHashCode(b));
    System.out.println(System.identityHashCode(c));
  }
}

Exemple de sortie (ce sera différent à chaque fois, mais les deux premiers seront toujours les mêmes, et le troisième sera pratiquement toujours différent):

366712642
366712642
1829164700

En termes simples :

Int > > Sont des primitives..pour des opérations mathématiques simples. Vous ne pouvez pas les ajouter pour une collection.

Integer > > Sont des objets en eux-mêmes.. sont des emballages à ints. j'.e, ils peuvent être utilisés avec des collections (car ce sont des objets). Elles le sont collecté comme objets normaux par le GC.

MODIFIER:

public static void main(String[] args) {
    int i = 5;
    System.out.println(int.class);

    Integer i1 = new Integer(5);
    System.out.println(Integer.TYPE);

}

O/P : int
      int

Donc, fondamentalement, les deux renvoient un int. Entier.TYPE renvoie simplement le type primitif de la classe Integer. C'est vrai pour toute classe wrapper

Java gère les types primitifs par rapport aux types de classe de manière schizophrénique en définissant deux types pour chaque primitive.

Par exemple int est le type primitif et Integer le type de classe. Lorsque vous utilisez des génériques, vous êtes obligé d'utiliser un type non primitif, donc ArrayList<Integer> est autorisé mais ArrayList<int> pas.

Puisque vous voulez parfois effectuer une réflexion, cette dualité entraîne deux classes (sinon, comment pouvez-vous inspecter une méthode public int foo ();).

Dites que vous avez une classe:

public class Foo {

    private Integer value;

    public int value1 () {
        return value;
    }

    public Integer value2 () {
        return value;
    }

}

Le deux méthodes ne renverront pas toujours la même valeur, car value2() peut renvoyer null et value1() lancera une erreur d'exécution.

, Pour moi, la meilleure façon de comprendre int.class et Integer.class est d'arrêter de penser Integer est un wrapper (le type qui implique qu'il est "spécial"). En fait, il est plus facile, et probablement plus approprié, de considérer int comme un cas particulier.

Integer est juste une classe Java normale, rien de différent de par exemple String. Il dérive de Object, fonctionne comme Object, À l'exécution, vous pouvez créer une instance de Integer, l'instance prend une disposition de mémoire de type objet, par exemple avec un pointeur au début pointant vers le Integer.class, qui est ce qui permet le comportement d'exécution polymorphe de java.

Il n'y a vraiment rien de spécial encore à propos de Integer. si vous imaginez un Java sans booléen, int, long ces primitives, mais seulement avec Integer, Booléen, Long, etc., le système de type est en fait très cohérent.

Conceptuellement, vous pouvez penser à int comme une classe spéciale introduite plus tard pour des raisons de performance. Initialement, cela n'a rien à voir avec un entier. À l'époque où Java était créé, le maintien d'une disposition de mémoire de type objet pour les nombres simples est très coûteux pour les programmes arithmétiques lourds. Et la plupart des opérations arithmétiques n'impliquent même pas du tout la répartition dynamique polymorphe. Par exemple, il est beaucoup moins courant d'invoquer des méthodes telles que toString sur un nombre.

Int est spécial en ce sens qu'il s'agit d'une classe dont les "instances " sont disposées en mémoire avec la structure d'objet commun supprimée-seulement quatre octets consécutifs sans méta supplémentaire données.

En conséquence, vous ne pouvez pas faire 123.getClass() car la disposition de la mémoire d'exécution de int 123 n'a pas de pointeur de classe. int.class existe, il n'est absolument pas lié à Integer.class (encore). Dans un sens, int est plus similaire à Void, comme dans Void.la classe existe, mais vous ne pouvez jamais avoir l'objet o where o.class == Void.class.

Java pourrait simplement s'installer ici, int est int, Integer est Integer. Mais ce que les gens réalisent, c'est que bien que moins commun, il est toujours très utile de pouvoir traiter int comme un Java normal objet sinon, vous devrez toujours maintenir au moins deux ensembles de vos méthodes - un qui prend des objets normaux et un autre qui prend des primitives - même si les performances ne sont pas votre préoccupation. Dans ces scénarios, int se comporte en fait comme un entier. Java permet à cette conversion de se produire automatiquement à travers les processus de boxe automatique, rendant ainsi efficacement int et Integer liés.

Mais int est toujours int, et Integer est toujours Entier (par exemple int.class != Integer.class). Mais un champ supplémentaire est présenté en Entier.classe pour indiquer qu'il se rapporte à int.classe, c'est-à-dire Integer.TYPE. Donc Integer.TYPE == int.class. Pour moi Integer.TYPE est juste pour capturer le notionnel que Integer et int sont liés. Comment l'utiliser, ou s'il est même utile, dépend de vous.

En pratique, int et Integer sont toujours des types distincts là où cela compte. Par exemple:

void accept (int value);
void accept (Integer value);

Sont toujours considérés comme deux surcharges. Par conséquent, lorsque vous travaillez avec reflection, vous pouvez utiliser int.classe et Entier.classe pour différencier les deux.

Lorsque vous ne travaillez pas avec la réflexion ou une forme de méta-programmation, car vous ne pouvez pas naviguer vers int.la classe d'un objet, il est relativement rare de voir int.classe à utiliser dans votre code. Parfois, cela semble déroutant car la syntaxe de boxe automatique semble suggérer que vous devriez entrer int.classe:

int value = 1;
Class c = ((Object)value).getClass();

Mais ce n'est qu'une illusion, car au moment où vous faites ((Object)value), vous créez en fait une nouvelle instance entière avec la même valeur.

La seule fois dont j'ai besoin travailler explicitement avec int.classe et Entier.la classe consiste à construire une api générique <T> T getValue(String name, Class<T> type); où j'ai besoin de différencier si l'api est autorisée à renvoyer null:

int value = getValue("key", Integer.class); // will potentially throw NPE
int value = getValue("key", int.class); // will never throw NPE