Discussion :

[PhilippeGibault]

Bonjour,

Prochainement, je vais intégrer une nouvelle mission qui repartira "from scratch".


Je me pose des question d'architecture, mais également de construction.

A tout instant, je dois pouvoir construire le projet, indépendamment de l'environnement de développement, mais aussi du système d'exploitation.

Sachant que l'on doit durer, et s'adapter aux nouvelles JVM, la question se pose de partir du JDK 10.

Certains pensent qu'il faut partir du JDK 8, mais je ne suis pas d'accord.
Il vaut mieux épargner un travail de migration du JDK 8 au JDK 9/10.

Et comme on doit mettre à jour le projet pour qu'il puisse prendre le dernier JDK, je pense qu'il faut partir du JDK 10.

Voici donc ma question:

En Java 8, l'architecture du projet est, en résumé, la suivante:



J'ai identifié les différentes couches, les différents JAR et les dépendances.

Notez que l'on a, par couche, un JAR contrat (Interface + Template Method) et un JAR d'implémentation.

Ce choix permet:

1. Une implémentation pour différentes cibles (BDD, SOLR...) vu que le contrat peut rester le même (CRUD par exemple)
2. De tirer les JAR dans d'autre projets (Client lourd, chaîne de traitement ...)

L'ensemble du projet est construit par Maven.
On a un projet parent, et chaque projet hérite du parent (avec les dépendances indiquées).
On ajoute éventuellement d'autres JAR externes (Spring, JSF, Hibernate...)

Seulement, avec Java 9, et donc par extension, Java 10, on a une JVM modulaire.

On a plus des JAR, mais des jmod.

Je me dis donc que si on veut se plier à la philosophie Oracle (à partir de Java 9) et que l'on veut s'adapter aux futures JVM, il faut fabriquer des jmod.

Le schéma, très proche du précédent est donc le suivant:




Le WAR reste pour un serveur (comme Tomcat).
Les JAR ne sont autorisées que si elles sont extérieure au système (Spring, Hibernate...).

Ce qui m'amène la question suivante: Est-il possible, Dans la pratique, d'automatiser ça par un outil de build, et comment?

On est Maven, il y a un plugin qui fait des jmod (https://maven.apache.org/plugins/maven-jmod-plugin/) mais c'est une pré-realease.

Maven reste-t-il pertinent?

Si non, par quoi le remplacer?

Gradle est-il plus adapté?

Merci de vos retours.

[yildiz-online]

Quelques questions:

1) Pourquoi utiliser des technologies en perte de vitesse (jsf, war,...) ?
2) Pourquoi java 10 (qui n'est pas LTS) ?
3) Pourquoi jmod plutot que jar, quel est le besoin?
4) L'architecture en couche est vraiment le choix le plus pertinent pour ce projet?

[PhilippeGibault]

Quelques questions:

1) Pourquoi utiliser des technologies en perte de vitesse (jsf, war,...) ?
2) Pourquoi java 10 (qui n'est pas LTS) ?
3) Pourquoi jmod plutot que jar, quel est le besoin?
4) L'architecture en couche est vraiment le choix le plus pertinent pour ce projet?

1) L'équipe et l'entreprise ont des compétences en JSF. Mais là dessus, je suis ouvert. Si on ne prend pas JSF, ça me va aussi. Pour le WAR, je ne vois pas bien ce qui peut être utilisé pour déployer (pour la partie concernée) sur un Tomcat.
2) Notre projet doit s'adapter pour fonctionner avec la dernière version de la JVM. La version 10 est la dernière actuellement. La 11 est pour l'année prochaine...
3) Il me semble que Oracle a défini les modules (les jmod) et que l'on va vers des architectures modulaires. J'ai le sentiment que c'est vers ça, à long terme que l'on va aller. A minima, il faudrait que je fasse des JAR avec module.info. J'essaye d'anticiper de possibles évolutions.
4) C'est du classique, et c'est efficace.

Ma question est plus d'ordre pratique, étant donné que je suis dans une phase de réflexion. Si on part sur une architecture de ce type (Java 10 + jmod), Est-ce possible de le faire (je pense que oui) mais surtout, de le faire compiler à partir d'un outil de build indépendant de l'IDE et du système d'exploitation. Là est ma question.

[yildiz-online]

1) Ok pour JSF, les jars avec un tomcat embarqués (spring boot) ont le vent en poupe actuellement plutôt que les wars.
2) 11 est dans 1 semaine, c'est risqué de partir sur un non LTS, dans 6 mois, plus de support.
3) Les avantages de jmod sont pour l'inclusion de fichiers dans le package, les jars(avec module-info) sont tout à fait recommandés hormis besoins particuliers.
4) Classique oui, efficace, pas forcément, ça dépend du projet.

Attention cependant avec les modules, rares sont les librairies qui sont portées.

Pour répondre à ta question, oui on peut.