Discussion :

[cormnsa]

Bonjour,

Pour l'instant, je suis en JDK11, mais je me pose la question de migré en JDK25 (si LTS).
Mais, je me dis qu'il serait bien d'utiliser les nouvelles fonctionnalité des JDK, en outre la class reccord.

Mais, migré pour juste avoir une version plus récente, je ne suis pas certains que cela soit très un bon choix.
Donc, je brainstorm...

Pour ce qui est de la class de type reccord, je peux par exemple convertir celle-ci :

Code :

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

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
public class def_formula
	{
	int action = 0;
  int type = 0;
  String operande = "";
  String operation = "";
  
  /**
   * Constructor
   * 
   * @param iAction
   * @param iType
   * @param sOperande
   * @param sOperation
   */
  public def_formula(int iAction, int iType, String sOperande, String sOperation)
    {
    action = iAction;
    type = iType;
    operande = sOperande;
    operation = sOperation;
    }

	/**
	 * @return the action
	 */
	public int getAction()
		{
		return action;
		}

	/**
	 * @return the type
	 */
	public int getType()
		{
		return type;
		}

	/**
	 * @return the operande
	 */
	public String getOperande()
		{
		return operande;
		}

	/**
	 * @return the operation
	 */
	public String getOperation()
		{
		return operation;
		}
	}

en

reccord def_formula(int action, int type, String operande, String operation) {}

Mais, cela veut dire que je dois remplacer les appels :

• getAction() par action()
• getType() par type()
• getOperande() par operande()
• getOperation() par operation()

D'ailleurs, question annexe : une class de type reccord peut-il être encapsulé dans une ArrayList ou un Vecteur ?

Ce qui donnerait (en utilisant les class de type reccord) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 def_formula formula = null;
 
  for(int i = 0; i < alFormula.size(); i++)
       {  
       formula = alFormula.get(i);
     	 priorite = formula.getAction();
     	 PLog.debug("executing line " + priorite);
 
         double value1 = 0, value2 = 0;
 
     	   switch(formula.type())
....
st = new StringTokenizer(formulaoperande(),";");

Est-ce que cela vaut la peine de faire ce genre de modification ou vaut-il mieux laisser ainsi.

Bref, il y a deux questions dans ce post :
- Interet à migrer en JDK 25
- Usage d'adapter certaines class en class de type reccord.

Désolé si le post est un peu chao, mais en écrivant, je réfléchis et "brainstorm"

[Invité]

Salut,

Migrer vers un JDK recent peut se faire pour plusieurs raisons:

-Volonte de reduire sa dette technique et avoir une version supportee.
-Volonte de reduire les risques de securite et ameliorer les performances.
-Volonte d'utiliser les nouvelles fonctionalites.

On pourrait aussi ajouter rationaliser les versions dans l'infra, etre compatible avec une lib recente...

Pour les cas 1 et 2, juste remplacer la JRE sera suffisant, pas besoin de modifier ton code, a condition qu'il n'utilise pas de fonctionalites depreciees (com.sun, finalize, applet...)
Pour le cas 3, avec les records par exemple il faut alors en plus de la JRE, modifier ta chaine de construction en consequence, puis le code.
Si tu veux introduire les records, et rester compatible avec les beans tu peux par exemple toujours commencer par implementer les getters qui renvoient les fonctions implicites ou directement les objets, comme ca seule la classe record est modifiee dans un premier temps et si pour une raison les records ne conviennent pas, tu peux revenir en arriere sans autre impact.

[bouye]

D'ailleurs, question annexe : une class de type reccord peut-il être encapsulé dans une ArrayList ou un Vecteur ?

Un objet qui est dans un Record peut etre utilise dans n'importe quel contexte ou on peut utiliser un objet (voir Enum qui est dans le meme cas).
Les seules choses qui sont particulier au record sont :

• La manière de declarer ce code.
• Le type est final.
• Les membres sont implicites (base sur la declaration).
• Le constructeur par default est implicite (base sur la declaration).
• toString() est implicite.
• hashCode() est implicite.
• equals() est implicite.
• Les getters sont implicites (base sur la declaration).
• L'instance est immutable.

Pour le reste :

• Il est possible de rajouter des constructeurs (et on peut invoquer le constructeur par défaut).
• Il est possible de surcharger le constructeur par défaut (et on peut initialiser les membres a la manière classique).
• On peut rajouter des membres statiques (finaux ou pas).
• On peut rajouter des méthodes d'instance ou statiques.
• On peut étendre des interfaces (mais pas des classes bien sur).

[miaous]

Il y a aussi que les attributs sont final et de confiance c.a.d qui n'est pas possible de les modifier par reflectivité ( via setAccesible ).

cela permet à la JVM de faire des optimisation car on ne peut le modifie par derrière ( d oula JEP pour les futueur version de java de rentre final vraiment final ).

A bote que ce comportement est applique aussi aun champ final des lambda ( cas où l on fait une capture).

[thelvin]

On précisera au passage que ce n'est pas de la magie. La JVM considère ça comme de confiance et d'autres pas, sur la base d'un ensemble de considérations pas très absolues et qui ont l'air un peu arbitraire de loin. Les champs ne sont pas dans une page mémoire en lecture seule et il reste des moyens de les modifier. Il est assez compréhensible que la JVM décide d'optimiser comme si ça n'arrivait pas, mais du coup elle pourrait aussi faire ça dans d'autres situations, sans forcément s'imposer d'abord le "final is really final" qui n'est finalement qu'une considération interne à la JVM et ce qu'elle garantit quand c'est par elle qu'on passe, plutôt qu'une véritable impossibilité de changer.