Nous sommes en préparation active des upgrade vers la v6.3 de nos référentiels.
Dans ce contexte, nous avons commencé à aligner nos codes Java sur le niveau d’exigences requis par le nouveau compilateur ECJ. Néanmoins, compte tenu de l’effort potentiellement nécessaire pour mettre nos codes à niveau, nous envisageons de prédéfinir une valeur surchargée de la variable JAVA_COMPILER_OPTIONS dans nos bases installées en v6.2 avec une configuration moins stricte.
Cela peut-il poser un problème avec le processus d’upgrade interne de Simplicité ?
ECJ remonte par defaut plus de warnings, d’où l’introduction du param système JAVA_COMPILER_OPTIONS pour jouer, si besoin, sur ce que remonte ce compilateur sur son code (ça ne concerne bien que la compilation code applicatif).
Ce param système JAVA_COMPILER_OPTIONS n’existait pas en 6.2 et n’a donc aucun effet en 6.2
En 6.3 il est livré par défaut avec la valeur -g -warn:deprecation,unused,-unusedImport à savoir:
compilation avec les infos de debug -g => pas forcément nécessaire sur une instance de production
warnings en cas :
d’utilisation de choses obsolètes (deprecation) => à conserver impérativement et corriger rapidement ce que ça remonte car ce qui est deprecated risque de finir par poser des problèmes au fil des temps (un deprecated ne fait plus forcément ce qu’il faudrait, et finira par être supprimé après être passé au statut “for removal” ce qui générera alors des erreurs de compilation)
de présence de choses (variables, methodes, classes, …) inutilisées (unused) sauf au niveau des imports (-unusedImport) => le unused peut être nuancé plus finement (cf. les options possibles: Help - Eclipse Platform) mais c’est en général le signe de choses pas idéales
Quels sont les warnings remontés sur votre code ?
De manière générale tout warning de compilation est intéressant à investiguer en complément d’analyses externes (ex: Sonar) et de ce que remontent les outils de “linting” Java (Checkstyle) ou front (ESLint et Stylelint), ex: sur les modules de la Demo:
Oui nous sommes en phase sur ce qui doit être mis en œuvre.
Je cherche dans un premier temps à border le processus d’upgrade en diminuant au maximum les risques / problèmes en cascade (problème de compilation → recompilation à chaque clear cache → dégradation du temps de démarrage → interruption du monitoring CI/CD (timeout) → analyse spécifique sur la console GCP pour vérifier l’état courant du processus, …). Rien d’insurmontable pour la plupart mais certaines équipes sont moins averties que d’autres et relancent le pipeline sans avoir vérifié. Tout ce que je pourrais border en amont sera bienvenue.
D’où ma question : Si je défini sur une configuration 6.2 le paramètre JAVA_COMPILER_OPTIONS avec la valeur définie sur une 6.3 “out of the box” et surchargée avec une configuration plus permissive, est-ce qu’il peut y avoir une incidence sur le processus d’upgrade en 6.3 ?
Je communique par ailleurs une liste de recommandations aux équipes pour lever les erreurs bloquantes en amont car il n’y a pas que des warnings (certaines portions du code ne passent plus la compilation).
Le patch 6.3 créé le param système en upsert et sans la sys_value2 donc s’il est déjà précréé avec une valeur surchargée c’est bien cette valeur surchargée qui sera prise en compte en 6.3 (en 6.2 ce param n’existant pas).
Ce param en tant que tel n’a pas d’impact sur le processus d’upgrade niveau plateforme, c’est juste qu’il sera pris en compte à la recompilations du code applicatif lors des clear caches.
Pour limiter les risques d’erreur de compilation (les warnings ne sont pas bloquants) il convient d’anticiper le refactoring de son code dès la 6.2, en particulier corriger toutes les utilisations de deprecated qui trainent => certaines des choses dejà deprecated en 6.2 passent, en effet, en deprecated “for removal” en 6.3. Par contre les choses qui deviennent deprecated en 6.3 ne le sont jamais directement “for removal” donc pas bloquant (mais idéalement il faudra refaire une chasse aux deprecated une fois migré en 6.3 histoire d’anticiper le prochaines versions, avec ECJ ce sera plus simple car ça sortira en warnings à la compilation)
Ensuite il faut vérifier si on est concerné par les potentiels breaking changes indiqués dans la release note de la 6.3, hormis la suppression de la lib commons-discovery (qui a peu de chances d’être utilisée) et la suppression du support de l’API v1 OpenDataSoft (qui de toute façon n’existe plus coté OpenDataSoft), il ne devrait pas y avoir de pb (à priori vous n’utilisez pas le connecteur OIC FranceConnect legacy non plus)
Par contre pour avoir toutes les features de développement il est impératif de se mettre explicitement en “development mode” (ex: vai la ver d’en DEV_MODE="true") car en 6.3 certaines features sont désormais inhibées par défaut (et ce sera encore plus vrai en 7.0).
C’est aussi l’occasion de se reposer, plus généralement, les bonnes questions vs les Guidelines de sécurité entre vos instances de dev/test/preprod/prod
