Pourquoi Java n'autorise-t-il pas l'utilisation d'en-têtes comme en C ++

J'ai une question pour laquelle je n'ai pas trouvé de réponse à l'exception de la réponse suivante qui ne répond pas à mes exigences:

"Parce que James Gosling ne voulait pas"

Je sais que Java peut avoir des interfaces (uniquement des fonctions virtuelles pures, pas d'attributs), mais ce n'est pas exactement la même chose que les définitions de classe.

La réponse suivante qui ne répond pas à mes exigences: "Parce que James Gosling ne voulait pas."

C'est pourtant la bonne réponse. L'équipe de conception linguistique (Gosling, Sheridan, Naughton, plus tard Bill Joy, Ken Arnold, etc.) a décidé que les en- têtes causaient plus de problèmes qu'ils n'en résolvaient . Ils les ont donc conçus et ont démontré qu'ils pouvaient créer un langage parfaitement utile sans en avoir besoin.

De la section 2.2.1 du livre blanc de Java Language Environment :

Le code source écrit en Java est simple. Il n'y a pas de préprocesseur, pas de # définition et capacités associées, pas de typedef, et en l'absence de ces fonctionnalités, plus besoin de fichiers d'en-tête. Au lieu des fichiers d'en-tête, les fichiers source du langage Java fournissent les définitions d'autres classes et leurs méthodes.

Définitions redondantes, synchronisation des fichiers, définitions conflictuelles, définitions masquées - rien de tout cela ne se produit en Java, car vous n'avez pas d'en-tête. Si vous voulez voir une définition de classe nue, vous pouvez en générer une directement à partir d'un fichier .java - par exemple, la plupart des IDE vous montreront la structure d'une classe dans une barre latérale, ce qui revient au même.

Il n'y a pas vraiment besoin en C ++ d'avoir les définitions et déclarations de classe dans des fichiers séparés. Cela signifie simplement que vous pourriez, au moins dans les jours C, effectuer l'analyse en un seul balayage de haut en bas du code. Sur les machines sans stockage à accès aléatoire, c'était un gros problème!

Avoir des en-têtes vous a également permis de publier l'interface dans votre bibliothèque de code en fournissant l'en-tête sans avoir à révéler le code source. Malheureusement, en C ++, vous devez également révéler les données privées des membres, ce qui a conduit à des solutions comme l'horreur de pimpl .

Il y a eu des tentatives pour créer un environnement C ++ où tout était stocké dans une structure de type base de données et il n'y a pas de fichiers mais cela n'a pas fonctionné.

En raison du principe DRY . En Java, les informations nécessaires pour utiliser des classes dans un package (ou classe) sont contenues dans le fichier .class. La création de fichiers d'en-tête séparés contenant les mêmes informations impliquerait de les répéter à deux endroits.

Dans chaque langue - il y a deux étapes pour créer du code binaire final - la compilation et la liaison (bien sûr, il y a un chargement mais cela n'a pas beaucoup d'impact ici). Au moment de la compilation, il suffit de placer les crochets (la spécification des fonctions qui seront appelées) à l'endroit approprié. L'éditeur de liens les rejoint réellement lorsque le code réel est disponible. Jusqu'à présent, il n'y a aucune différence entre C ++ et Java.

Il existe cependant un besoin pour C ++ d'avoir une déclaration et une définition distinctes. Si vous conservez l'implémentation dans l'en-tête et si le fichier d'en-tête change, le code qui lui est lié doit être recompilé. Là où, comme si la définition se trouve dans un fichier séparé, le code n'a besoin que d'être re-lié.

Comprenez que C ++ a une option pour avoir une liaison statique, ce qui implique que le code objet est fixé avec l'application appelante. Veuillez noter qu'en C et C ++, il n'est pas invalide d'avoir la programmation dans le fichier d'en-tête ou même de faire #include. cela signifie seulement que vous devez vous soucier de la façon dont la liaison se produit avec ces fichiers objets.

La situation à Java est très différente. Chaque fichier de classe est compilé avec le fichier .class. En effet, la nécessité d'une compilation de fonction de classe appelant qui est servie comme une section d'en-tête dans le fichier .class. Cependant, en Java, la liaison finale se fait uniquement à l'intérieur du Runtime (la machine virtuelle) uniquement avec cette spécification du code d'octet du fichier de classe.

Voir ceci et cela

En effet, les interfaces et les inclus sont les en-têtes; les définitions sont donc identiques aux binaires et ne peuvent pas être désynchronisées. C'est l'une des meilleures décisions de conception en Java, mais c'est un inconvénient mineur qu'il n'y a aucun moyen de regrouper ces déclarations pour la compacité et la cohérence.

Une bonne raison d'avoir des inclusions est de séparer le code que vous voudrez peut-être réutiliser (comme les définitions courantes) du code spécifique à un projet donné. Java veut que vous spécifiiez une seule classe ou interface par fichier et cela réduit principalement le besoin d'en-têtes inclus - car vous aurez déjà les parties partagées dans leurs propres fichiers.

En outre, les compilateurs et les systèmes de génération peuvent vouloir mettre en cache les en-têtes précompilés pour éviter de les analyser plus d'une fois.