Si vous parcourez le projet Java dans GitHub, vous trouverez généralement un fichier nommé package.html, dont le contenu est le suivant:
<HTML>
<BODY>
Utils: Helpful things, which shouldn't implement against an Interface.
<p>
@since 1.0
</BODY>
</HTML>
Le sens est clair. Ce fichier décrit quel type de classe Java doit y être placé. Cette grammaire permet d'utiliser plusieurs commentaires pour développer les informations. Un autre bon effet est qu'en tant qu'espace réservé, il est généralement inconnu du développeur, et il est généralement inconnu du développeur. Permettez-moi d'expliquer rapidement ce que je veux dire. Bien sûr, nous sommes dans le contexte du développement Java, et au moment où vous démarrez le projet, vous devez créer une structure de répertoire. Lorsque vous utilisez un outil de construction comme Maven, vous pouvez démarrer votre projet en exécutant un prototype. Si vous utilisez un IDE à usage général tel que NetBeans, vous pouvez choisir parmi un grand nombre de modèles. Après avoir effectué cette étape, il est généralement d'abord soumis à un système de gestion de code source (SCM) tel que git ou Subversion. Mais il y a un petit problème. Git ne vous permet pas de soumettre des répertoires vides. Comme solution, de nombreux développeurs ont créé des fichiers cachés appelés .keept. Cette pratique est courante et établie, mais lorsque vous créez un package vide et placez package.htm, vous pouvez résoudre deux problèmes. Tout d'abord, Git vous permet de soumettre un répertoire, et vous avez inclus la documentation du développeur, qui devrait être incluse dans le package de documentation.
Le fichier package-info.java introduit dans Java 5 est moins courant. Le but de ce fichier est équivalent à package.htm - c'est juste une méthode plus récente, et c'est également la méthode officiellement recommandée par Oracle pour décrire les packages logiciels. Certains développeurs pensent que l'utilisation de fichiers Java comme documents API est un abus car ils ne contiennent pas de code. La plus grande différence qui peut être utilisée est le commentaire du package. Un autre argument est que, comme Java 9 et le projet Jigsaw sont utilisés pour la modularité, le fichier module-info.java a été introduit dans le répertoire racine du projet. Ce fichier est le descripteur de l'ensemble du module. Dépendances définies qui ont été utilisées, packages accessibles et autres contenus. Je pense que c'est un bon style, il ne confondra pas tout et utilisera des fichiers java comme descripteurs. Je pense que la nouvelle méthode apportera plus de flexibilité. Par exemple, vous pouvez placer un commentaire à la compilation dans package-info.java au lieu de le placer dans une classe. Cette centralisation évite les commentaires manquants et réduit la duplication.
Si votre projet contient à la fois package.html et package-info.java, la source préférée de JavaDoc sera toujours package-info.java. Si vous souhaitez créer un fichier package-info.java dans l'IDE Eclipse à l'aide de classes standard, il échouera en raison des conventions Java. Pour résoudre ce problème, il vous suffit d'accéder au package dans lequel vous souhaitez placer le fichier d'informations et de créer un nouveau package. Vous pouvez nommer ce package package-info.java.
de: https://dev.to//elmardott/the-meaning-of-package-htm-vs-package-info-java-4emi
