Compatibilité Java 8 côté client a minima (Java 11 imposé mais trop limitatif)

[fredericBregier]

Hello,
Je n'ai pas regardé encore comment vous construisez les binaires (jar) Java, mais cet article est me semble-t-il assez en phase avec votre cas :
https://medium.com/uptake-tech/migrating-to-java-11-while-maintaining-a-java-8-client-library-f618a3ca6499

L'idée générale est :

• Le coeur (non client) est écrit et compilé en Java 11 (mais impose bien sûr d'être exécuté en Java 11, et donc que tout un chacun dispose d'une telle version de Java sur ses OS)
• Les clients (librairies) sont écrites et compilées en Java 8 afin d'être compatible Java 8 (pas de pression sur les "clients" externes qui utilisent vos outils).

Malheureusement, pas moyen, selon la littérature, d'avoir une compilation d'un code source Java 11 vers un code Java 8 sans risque sans cette option -release qui check la compatibilité du code source (et donc impose les changements dans le code source pour être compatible). Pas de compatibilité descendante (11 vers 8), mais uniquement ascendante (8 vers 11).

En limitant les modifications de compatibilité aux librairies dites "clientes" (et elles sont nombreuses dans Vitam), cela restreint la portée de maintenir Java 8 dans le code (10 à 20% du code total ?). C'est un moindre mal, sans doute.

Qu'en pensez-vous ?

[fredericBregier]

En regardant les pom.xml, vous compilez en effet en Java 11 pour l'ensemble (coeur Vitam et "client").

Donc incompatibilité à partir de la version 3 avec tous ceux qui utilisent et sont compatibles avec Java 8 (> 80% du parc)...

Peut-être faire comme certains grands projets qui ont différentes distributions: jdk11 / jdk 8 ?

A minima, si pour le coeur c'est compréhensible (encore que ?), pour les parties clientes, cela vous coupe d'un grand nombre d'acteurs...

Qu'en pensez-vous ?

[fredericBregier]

Confirmation: avec les jar Vitam, Java 11 devient une condition sine qua non de l'usage de Vitam.

Exemple de build maven avec Java 8 pour un programme utilisant les dépendances "'clientes" Vitam :
java.lang.UnsupportedClassVersionError: fr/gouv/vitam/common/server/application/junit/ResteasyTestApplication has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Conséquences : soit les autres projets migrent eux-aussi à Java 11, interdisant à tous leurs clients avec Java 8 de l'utiliser, soit ils ignorent la version 3.0.x de Vitam et restent définitivement en version 2.X...

Je pense que votre argument de "les clients ont des OS qui imposent Java 11" ne justifiait pas le passage en Java 11 de vos sources et binaires, car un Jar en Java 8 fonctionne sous Java 11, à l'inverse un jar en Java 11 ne fonctionnera jamais sous Java 8. Vous vous coupez donc de nombreux utilisateurs, ce qui me semble contraire à ce que vous annonciez.

[fredericBregier]

Pour info, côté binaire, voici mes dépendances (hors test):

• access-external-api
• access-external-client
• common-database-public
• common-http-interface
• common-public
• common-public-client
• ingest-external-api
• ingest-external-client

Côté tests, il faut ajouter:

• access-external-rest
• access-internal-api
• access-internal-client
• access-internal-common
• common-database-private
• common-format-identification
• common-junit
• common-private
• common-security
• common-storage
• functional-administration-client
• functional-administration-common
• ingest-external-common
• ingest-external-core
• ingest-external-rest
• ingest-internal-api
• ingest-internal-client
• internal-security-client
• internal-security-common
• logbook-common
• logbook-common-client
• logbook-operations-client
• metadata-api
• storage-driver-api
• storage-engine-client
• storage-engine-common
• workspace-api
• workspace-client
• workspace-common

Le besoin n'était que d'adresser les API externes Ingest et Access, plus les fonctions de validation d'opérations longue durée. Pour les tests automatisées, il faut simuler un certain nombre de choses, d'où les dépendances étendues.

Et je dois de plus m'assurer en version 3.0.1 avec Java 11 (j'ai les deux sur mon poste) d'une possible régression fonctionnelle suite à l'upgrade de 2.5 à 3.0.

[fredericBregier]

Selon mes informations, il serait utile d'avoir l'une des deux options suivantes de votre côté pour éviter de perdre tous vos clients qui ne peuvent pas monter en Java 11 (8, 9, 10).

Je rappelle : Ceux qui sont en Java 11 peuvent tourner des "jar" compilés en Java 8, mais pas l'inverse.

Option A) Tous les jars sont compilés en Java 8, ce qui les rend compatibles pour Java 8, 9, 10, 11 et suivants... Clairement ce que je préconiserais

• Intérêt : zéro effort pour vous, un seul jar, un seul pom et pas de régression

Option B) Vous avez 2 séries de Jar: vitam-xxx-java8.jar et vitam-xxx-java11.jar (ou l'un des deux est en sans la précision mais implicitement à la version que vous choisissez). Cela complexifie le travail pour les partenaires car il faut charger explicitement les "bons" jar pour sa JVM ce qui est contraire à l'usage (cela supposerait de faire un pom.xml de dépendance pour Java 8 et un autre pour Java 11 pour lister les "bons" jar). Bref, en clair, cela complexifie les usages au sein d'un éditeur type Eclipse ou IntelliJ du fait de la grande difficulté d'avoir les bons codes à la bonne version. La charge est clairement de votre côté à maintenir un pom.xml pour Java 8 et un autre pour Java 11, sur la base des mêmes dossiers sources, en maintenant 2 streams de versions identiques à la version JVM près (exemple: groupe vitam-jvm8 et vitam-jvm11 comme base du pom).

• Plusieurs projets font cela mais c'est une charge (guava, kotlin, jackson-datatype, ...)

• A noter que si vous maintenez deux versions (8 et 11), il vous faudra vous assurer que tous les modules complémentaires (dépendency) seront eux aussi compilés pour au plus Java 8 (via Animal Sniffer Maven plugin par exemple), sinon vous aurez une release cassée (un jar en Java 8 mais une dépendance par exemple en Java 11 => break).

[fredericBregier]

A noter que ce passage en Java 11 conduit à créer une version dégradée des outils clients de Vitam puisque les dépendances sont très différentes et incompatibles (Java 8 vs 11)... cf example WaarpVitam waarp/WaarpVitam#5

[fredericBregier]

Il semble que la 3.0.3 ne fixe pas ces points. Je me trompe ?