Problèmes rencontrés lors de la migration de l'APE de JDK 8 vers JDK 11

Les tests unitaire de l'APE ont montrés plusieurs problèmes lors de l'exécution de l'APE sous JDK 11 :

  • L'affichage d'une date sous la forme ${.dada_model.ma_date?string.short} est différent en langue française :

Sous JDK 8, l'output est par exemple 12/05/25 (date sur 2 chiffres).
Sous JDK 11, l'output est par exemple 12/05/2025 (date sur 4 chiffres).

C'est dû au fait que l'implémentation du JDK s'appuie sur la norme CLDR qui a changé entre la v8 et la v11.

  • L'utilisation de la macro hardisAdv.groupList peut avoir un ordre d'affichage différent lorsque qu'on fait un group by sur un objet qui a une valeur de type Freemarker Date / Time / DateTime ET que le template est exécuté avec une locale "fr" :
    Sous JDK 8, l'affichage est correct,
    Sous JDK 11 l'affichage est incorrecte car les dates / heures / date-heures ne sont pas triées correctement. 

C'est dû au fait que la classe Java JDK 11 Calendar utilisée ne se comporte pas de la même façon selon que la locale renseignée en entrée (au format  IETF BCP 47) soit "fr" (locale incomplète avec code langue seule qui provoque une mauvaise comparaison de dates / heures / date-heures) ou "fr-FR" (locale complète avec code langue et code pays qui provoque une bonne comparaison de dates / heures / date-heures).

Donc pour que le fonctionnement en JDK 11 soit identique à JDK 8 il est nécessaire que la locale soit complète.


Problèmes rencontrés lors de la migration de l'APE de JDK 8 / 11 vers JDK 17

Les tests unitaire de l'APE ont montrés un problème lors de l'exécution de l'APE sous JDK 17 :

  • Suivant la police utilisée, l'affichage d'un numérique peut différé sur le caractère de séparateur des milliers :

C'est dû au fait que l'implémentation du JDK s'appuie sur la norme CLDR qui a changé entre la v11 et la v17.

Sous JDK 11, le caractère de séparateur des milliers est U+00A0 (NO-BREAK SPACE).

Sous JDK 17, le caractère de séparateur des milliers est U+202F (NARROW NO-BREAK SPACE).

Source : https://stackoverflow.com/questions/70865403/why-numberformat-working-different-for-openjdk11-and-openjdk17

Donc il se peut que la police utilisée ne supporte pas le caractère NARROW NO-BREAK SPACE et affiche un caractère erroné à la place.

Source : https://www.fileformat.info/info/unicode/char/202f/fontsupport.htm



  • Aucune étiquette