java.lang.Integer pas finalisable ?

Bonjour/Bonsoir a tous
Essayant de me débarrasser le plus possible des types primitifs, l'utilisation de Integer dans le code 1 m'envoie le warning

Citation:

---

attribute value must be constant

---

code 1

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

import javax.validation.constraints.*; import java.io.Serializable;     public class Answer implements Serializable {   private static final long serialVersionUID = 2924588702765525250L; public static final Integer ANSWER_MAX_SIZE = 65000; private String answer;   public Answer() { super(); }   @NotNull @Size(max = ANSWER_MAX_SIZE) public String getAnswer() { return answer; }     public void setAnswer(String answer) { this.answer = answer; } }

---

code 2

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

import javax.validation.constraints.*; import java.io.Serializable;     public class Answer implements Serializable {   private static final long serialVersionUID = 2924588702765525250L; public static final int ANSWER_MAX_SIZE = 65000; private String answer;   public Answer() { super(); }   @NotNull @Size(max = ANSWER_MAX_SIZE) public String getAnswer() { return answer; }     public void setAnswer(String answer) { this.answer = answer; } }

---

Je ne comprends pas pourquoi mon utilisation de java.lang.Integer déclaré public static final ne me permet pas qu'il soit vue comme une constante alors que le type primitif int dans le code 2 lui oui.

Integer est une classe, int est un type, je ne suis pas sûr mais ça vient probablement de là...

Tout simplement parce que les constantes ne sont possible qu'avec les types primitifs et la la classe String.

Toutes les autres classes ne sont pas gérées en tant que constantes mais en tant que référence statique finale classique. Pour plus de précision sur les constantes: http://java.developpez.com/faq/java/...TION_constante

Merci d'avoir préciser la chose de manière plus propre ça va mieux dans ma tête :)

bonjour,

Mais pourquoi souhaites tu enlever les primitifs ? quel est l’intérêt ?

Merci de vos réponses et participation au sujet, le but de ma démarche est d'avoir une approche tout objet tout simplement.

Sachant qu'on considère à présent le type String plus ou moins comme un type primitif(puisqu'après tout ce n'est qu'un char[]) je ne pense pas qu'il soit faisable d'ôter tous les primitifs mais bon courage quand même :)

la démarche est absurde. l'utilisation de type primitif n'est pas incompatible avec la poo :calim2:

C'est bien ce que je redoutais, les primitives ne sont effectivement pas incompatible avec la POO !
De plus tu as besoin de les garder, car tu risques au final d'être confronté a des problèmes. Et tu va considérablement dégrader les perfs, il y a un certains nombre de chose que tu dois rater.
On va prendre un exemple simple :

Code:

---

1 2	Integer ANSWER_MAX_SIZE = 65000; // depuis la 1.5 uniquement, hé oui ca marche pas en 1.4

---

Lorsque tu écris ça c'est comme si tu écrivais :

Code:

---

1 2	Integer ANSWER_MAX_SIZE = new Integer(65000);

---

depuis le 1.5 il est apparu ce que l'on appel l'autoboxing, c'est un avantage mais aussi (pour celui qui ne sais pas ce que c'est) une catastrophe.
En gros, ca permet de transformer un type simple en son wrapper sans passer par un new explicitement. Pratique lorsque l'on souhaite stocker des int dans une liste par exemple.
tu peux donc faire :

Code:

---

1 2 3 4

Integer ANSWER_MAX_SIZE = 65000;   int valSimple = ANSWER_MAX_SIZE;

---

Maintenant je te laisse imaginer ce que fait le code suivant :

Code:

---

1 2 3 4 5 6

Integer ANSWER_MAX_SIZE = 65000;   Integer uneVal = 10;   Integer result = ANSWER_MAX_SIZE + uneVal;

---

Sérieusement, laisses tomber le passage en tout objet et garde les primitive.

À la limite personne n'a parlé de types primitifs qui seraient "incompatibles avec la POO."
Il a juste été question de "vouloir passer au tout-objet" sous-entendu pour profiter des avantages du tout-objet.

Alors dans d'autres langages, notamment par prototypage, je veux bien. Mais en Java, je serais curieux de savoir quel avantage on retire d'utiliser uniquement des types objets et jamais des types primitifs.
Il n'y en a pas, l'idée n'a pas de raison d'être.

Si le langage a été prévu pour, le tout objet peut se justifier mais ce n'est en effet pas le cas de Java.

L'auto-(un)boxing est juste une rustine conçue pour permettre d'utiliser facilement les types primitif dans les classes utilisant des génériques. L'utiliser pour faire comme si java était un langage purement objet peut être source de ralentissement, voire de bug.