Lorsque vous compilez vos fichiers Java , incorpore-t-il également vos javadocs et vos commentaires dans le fichier de classe?
Par exemple, si vous avez de grands javadocs, cela affecte-t-il la taille globale de votre fichier de classe? Ou le compilateur ignore-t-il tout en commençant par // et / * ?
3 Réponses :
Non, les commentaires ne sont pas compilés dans vos fichiers de classe. Cela inclut les Javadocs.
Au lieu de cela, vous devez utiliser un outil Javadoc (comme Sun / Oracle's ) sur le code source pour générer la documentation.
Non, le fichier de classe n'est que des données binaires.
Annotations May être conservée (selon l'annotation).
Les commentaires n'affectent pas la taille du fichier de classe.
non. Il existe plusieurs options de débogage qui affectent la taille d'un fichier de classe, mais les commentaires ne font jamais partie du fichier Quelques estimations:
Remarque: Commentaires (et donc Javadoc) ne sont jamais ajoutés au bytecode.
Pour voir ce qui finit dans le fichier .Class résultant.
-g: ligne ajoute simplement des informations de numéro de ligne (quelques octets)
-g: vars inclut les noms complets de toutes les variables. C'est généralement l'option la plus chère.
-g: source ajoute simplement le nom du fichier source (sans chemin).
-parameters fait des noms de paramètres de méthode accessibles via une réflexion. Ceci est indépendant de -g: vars .
.Class , utilisez javap -v plus le chemin du fichier.
Avez-vous essayé ça? Les Javadocs ne sont pas inclus même si -g: source est défini. J'ai essayé de décompiler des cours avec Jad.
@ctapobep: Je viens d'essayer avec Java 6 et 7 et vous avez raison: -g: source n'inclut pas le code source dans le fichier de classe. Quelques minutes de dérivation et de googling ne se sont pas présentées et que cette option fait vraiment: - /
Malheureusement, cette réponse est tout simplement fausse. Le code source Java, les commentaires ou les javadocs ne sont jamais inclus dans le fichier .Class . L'option -g: source amène simplement que le compilateur émet le chemin du fichier source (dénudé) en tant qu'attribut dans le pool .CLASS Pool constant.
@Stephenc je ne peux pas la supprimer car il est déjà accepté. Fixons-le. Qu'est-ce qu'un "chemin source dépouillé"?
C'est (Afaik) fondamentalement le chemin du chemin du fichier source avec un préfixe supprimé. J'avais besoin de plonger au plus profond du code pour déterminer exactement ce que ce préfixe est / comment il est déterminé. Il serait raisonnable de ne pas inclure les détails sur le décapage ... parce que nous parlons de quelque chose que ne ne fait pas ce que veut (ou veut éviter).
@Stephenc j'ai vérifié avec Javap. Il lâche le chemin du nom du fichier. Étant donné que vous pouvez déterminer le dossier du nom du package, cela permet probablement de comprendre le fichier source des classes intérieures et / ou lorsque vous avez plusieurs classes dans un seul fichier.
@depecated dans javadoc (à ne pas être confondu avec@depecated ) est utilisé pour définir un peu.