Nouveau petit Bug dans Java !

Voici le message que l’on reçoit quand on signale un Bug à Oracle.

« Dear Java Developer,

Regards,
Java Community Developer Support »

Lorsqu’Oracle n’était encore que Sun, j’avais au moins un retour sur l’évolution du rapport. Ce n’est plus le cas, les gens d’Oracle travaillent dessus mais ne le font plus savoir. On se retrouve avec un bug corrigé sans même le savoir ! C’est dommage.

En fait mon rapport a bien été pris en compte. Il s’agit bien d’un bug qui bénéficie du Bug ID : JDK-8133864.
Une solution a été trouvée, il semble également que cette correction ait été également intégrée à la future version Java 9.

De quoi s’agit-il ?
La partie visible d’Android « c’est du Java », c’était pour Google le moyen d’avoir une base de développeurs immédiatement opérationnels en attirant ceux qui développaient sur mobile avec Java. La différence tient dans l’évolution des versions. Google ne se préoccupe pas trop de la compatibilité avec les anciennes versions d’Android. Ce n’est pas le cas de Java qui assure une compatibilité avec toutes les anciennes versions de Java. Une application écrite en « Java 1 », il y a 10 ans fonctionne encore sous « Java 8 » et sans doute sur les versions futures.
D’où la complexité de mise au point de chaque nouvelle version. Cela entraîne également une augmentation de la taille de Java. La future version 9 apportera heureusement une réponse à cette problématique d’inflation.

Pour afficher les caractères Java 1 utilisait une méthode alors qu’à partir de la version 2 une autre méthode plus performante a été mise en place. Jusqu’à présent je n’avais pas fait la bascule à cause de ce bug mais aussi parce que je n’avais pas besoin des nouvelles possibilités de la version 2. Or l’affichage de signes spéciaux en mathématiques pourrait être plus aisé avec la nouvelle version.

J’ai donc signalé ce dysfonctionnement en essayant de trouver son origine.
Comme le bug précédent, il s’agit encore d’un problème de « descendance ».
Ce type de bug persiste en raison du nombre très restreint de programmeur ayant utilisé l’aborescence de swing. Partie un peu complexe de l’API Java.

Le point au 01/06/2016. Le bug est corrigé sur La version de développement de Java 9 à partir de b119 mais cette correction a révélé qu’il y avait un autre problème. Ce dernier est, selon moi, antérieur à cette correction. Il n’était pas visible à cause du problème d’affichage. Donc retour à la page de déclaration de dysfonctionnement. Le scénario est le même que précédemment : pas de retour ! Mais il a été signalé à l’équipe de développement qui l’a bien pris en compte, son identifiant est : JDK-8158209. Pour son traitement c’est ici.

Le point au 24/08/2016 Finalement, il semblerait que c’est l’introduction de Harbuzz qui soit à l’origine du problème. Bon, pour suivre tout cela prenez ce chemin.

Le point au 18/03/2017 Un membre de l’OpenJDK a pris un peu de temps pour examiner puis intégrer mes correctifs à JDK9(ea)b161. Les modifications ont ensuite été portées vers JDK10 prenez ce chemin.

En conclusion : En cas de signalement de bug, il faut suivre sa demande et le travail des développeurs pour rester informé. Le meilleur moyen étant les listes de diffusion de l’OpenJDK. Un problème en cache un autre. Une nouveauté peut introduire d’autres problèmes. Sauf retrait des modifications apportées, 6 ans ont été nécessaires pour arriver à bout du problème d’origine.

Position du bug discuté sur cette page dans ces 6 années.

JDK-7169915 : Swing Table Layout Update (2011-07-29 15:04),
JDK-7169915 : Swing Table Layout bad repaint of the row (2012-05-18 02:04),
JDK-8133864 [REGRESSION] : Incorrect i18n text document layout (2015-08-07 19:46),
JDK-8143177 [REGRESSION] : Integrate harfbuzz opentype layout engine per JEP258 (2015-11-17 15:58).
JDK-8158209 : Editing in TableView breaks the layout, when the document is I18n, resolved in build JDK 9 b161 (2016-05-27 03:27),
JDK-8177009 : Editing in TableView breaks the layout, when the document is I18n (2017-03-17 ?? : ??),