Comment dois-je nommer mon module Java 9?
Supposons que j'ai une bibliothèque avec groupId = org.abc et artifactId = myLibrary. Quel est le nom recommandé pour le nom du module: myLibrary ou org.abc.myLibrary? Existe-t-il un guide officiel pour un schéma de dénomination?
Pendant un certain temps, il y avait deux opinions différentes sur votre question, mais pendant le développement du système de modules, la communauté a opté pour l'approche DNS inversée.
Noms de modules uniques - DNS inversé
Ici, l'hypothèse est que les noms de module doivent être globalement uniques. Compte tenu de cet objectif, le moyen le plus pragmatique pour y parvenir suit la stratégie de dénomination des packages et inverse un nom de domaine auquel les responsables sont associés. L'état du système de modules le dit :
Les noms de module, comme les noms de package, ne doivent pas entrer en conflit. La façon recommandée de nommer un module consiste à utiliser le modèle de nom de domaine inverse qui a longtemps été recommandé pour nommer les packages.
De plus, Mark Reinhold écrit :
Il est vivement recommandé que tous les modules soient nommés conformément à la convention inverse de nom de domaine Internet. Le nom d'un module doit correspondre au nom de son package d'API principal exporté, qui doit également suivre cette convention. Si un module n'a pas un tel package, ou si pour des raisons héritées il doit avoir un nom qui ne correspond pas à l'un de ses packages exportés, alors son nom doit au moins commencer par la forme inversée d'un domaine Internet avec lequel l'auteur est associé.
C'est assez clair et partagé par d'autres Java experts comme Stephen Colebourne .
Les modules sont supérieurs aux artefacts
Pendant un certain temps (début 2016), une autre recommandation a fait le tour. L'équipe JDK a déclaré que les noms de modules peuvent ne pas avoir à être uniques après tout "car les modules sont plus abstraits que les artefacts qui les définissent". Mark Reinhold écrit :
Choisissez des noms de module commençant par le nom de votre projet ou produit. Les noms de module (et de package) qui commencent par des noms de domaine inversés sont moins susceptibles d'entrer en conflit, mais ils sont inutilement verbeux, ils commencent par les informations les moins importantes (par exemple,
com,org, ounet), et ils ne lisent pas bien après des changements exogènes tels que les dons open source ou les acquisitions d'entreprises (par exemple,com.Sun.*).L'approche inversée des noms de domaine était judicieuse au début de Java, avant que nous disposions d'outils de développement suffisamment sophistiqués pour nous aider à gérer les conflits occasionnels. Nous avons de tels outils maintenant, donc aller de l'avant la lisibilité supérieure des noms de module et de package courts qui commencent par des noms de projet ou de produit est préférable à la verbosité onéreuse de ceux qui commencent par des noms de domaine inversés.
De plus, avoir des noms de modules qui n'incluent pas de domaine permettrait d'échanger ce module contre une autre implémentation tant qu'il a le même nom (et implémente la même API publique bien sûr).
Dans le courrier ci-dessus, Reinhold documente son changement d'opinion:
Certaines personnes peuvent préférer des noms plus courts et axés sur les projets, et ceux-ci peuvent être bien utilisés dans des projets limités qui ne verront jamais la lumière du jour en dehors d'une seule organisation. Si vous créez un module qui a même une petite chance d'être open-source à l'avenir, cependant, le cours le plus sûr est de choisir un nom DNS inversé pour lui au début.
Résumé
Le jury est de la partie et tous ceux qui ont rendu leur opinion publique sont d'accord sur le DNS inversé comme pour les packages.
Je pense que nous avons obtenu un "officiel" réponse de Mark Reinhold:
Il est vivement recommandé que tous les modules soient nommés conformément à la convention inverse de nom de domaine Internet. Le nom d'un module doit correspondre au nom de son package d'API principal exporté, qui doit également suivre cette convention. Si un module n'a pas un tel package, ou si pour des raisons héritées il doit avoir un nom qui ne correspond pas à l'un de ses packages exportés, alors son nom doit au moins commencer par la forme inversée d'un domaine Internet avec lequel l'auteur est associé.