Pourquoi personne n’utilise make for Java?

À peu près tous les projets Java que j’ai vus utilisent Maven ou Ant. Ce sont de bons outils et je pense que presque tous les projets peuvent les utiliser. Mais qu’est-il arrivé à faire ? Il est utilisé pour une variété de projets non-Java et peut facilement gérer Java. Bien sûr, vous devez télécharger make.exe si vous utilisez Windows, mais Ant et Maven ne sont pas fournis avec le JDK.

Y a-t-il un défaut fondamental avec make lorsqu’il est utilisé avec Java? Est-ce juste parce que Ant et Maven sont écrits en Java?

Le problème fondamental de Make et Java est que Make part du principe que vous avez spécifié une dépendance, puis une règle pour résoudre cette dépendance.

Avec basic C, pour convertir un fichier main.c en fichier main.o, exécutez “cc main.c”.

Vous pouvez le faire en Java, mais vous apprenez rapidement quelque chose.

Surtout que le compilateur javac est lent à démarrer.

La différence entre:

 javac Main.java javac This.java javac That.java javac Other.java 

et

 javac Main.java This.java That.java Other.java 

est nuit et jour.

Exacerber cela avec des centaines de classes, et cela devient juste intenable.

Ensuite, vous combinez cela avec le fait que Java a tendance à être organisé en groupes de fichiers dans des répertoires, vs C et d’autres qui tendent vers une structure plus plate. Make n’a pas beaucoup de support direct pour travailler avec des hiérarchies de fichiers.

Make aussi n’est pas très bon pour déterminer quels fichiers sont obsolètes, au niveau de la collection.

Avec Ant, il va parcourir et résumer tous les fichiers obsolètes, puis les comstackr en une seule fois. Make appelle simplement le compilateur java sur chaque fichier individuel. Si vous ne faites pas cela, vous aurez besoin de suffisamment d’outils externes pour montrer que Make n’est pas à la hauteur.

C’est pourquoi les alternatives comme Ant et Maven ont augmenté.

Le programme make vénérable gère assez bien les langages compilés séparément, tels que C et C ++. Vous comstackz un module, il utilise #include pour extraire le texte des autres fichiers include et écrit un seul fichier object en sortie. Le compilateur est un système unique, avec une étape de liaison distincte pour lier les fichiers objects dans un binary exécutable.

Cependant, en Java, le compilateur doit réellement comstackr d’ autres classes que vous importez avec import . Bien qu’il soit possible d’écrire quelque chose qui génère toutes les dépendances nécessaires à partir du code source Java, afin que make construise des classes dans le bon ordre une par une, cela ne prendrait pas en charge les cas tels que les dépendances circulaires.

Le compilateur Java peut également être plus efficace en mettant en cache les résultats compilés d’autres classes tout en compilant d’autres classes qui dépendent des résultats déjà compilés. Cette sorte d’évaluation automatique de la dépendance n’est pas vraiment possible avec make alone.

La question est basée sur une hypothèse incorrecte: un nombre non négligeable de développeurs utilisent make . Voir Outils de génération Java: Ant vs. Maven . En ce qui concerne les raisons pour lesquelles un développeur n’utiliserait pas make : de nombreux développeurs ne l’ont jamais utilisé ou l’ont utilisé et l’ont détesté avec un feu qui brûle plus que mille soleils. En tant que tels, ils utilisent des outils alternatifs.

En fait, make peut gérer la recompilation en une seule commande de tous les fichiers Java obsolètes. Modifiez la première ligne si vous ne souhaitez pas comstackr tous les fichiers du répertoire ou si vous souhaitez un ordre spécifique …

 JAVA_FILES:=$(wildcard *.java) # # the rest is independent of the directory # JAVA_CLASSES:=$(patsubst %.java,%.class,$(JAVA_FILES)) .PHONY: classes LIST:= classes: $(JAVA_CLASSES) if [ ! -z "$(LIST)" ] ; then \ javac $(LIST) ; \ fi $(JAVA_CLASSES) : %.class : %.java $(eval LIST+=$$< ) 

Toutes les autres réponses sur les mérites techniques de chacun sont vraies. Ant et Maven peut-être mieux adaptés à Java que make, ou, comme le fait remarquer Hank Gay, ils ne le sont peut-être pas 🙂

Cependant, vous avez demandé s’il était important que Ant et Maven soient écrits en Java. Bien que sur StackOverflow nous ne considérons pas de telles pensées (fermées! Pas liées à la programmation! Etc.), bien sûr, cela fait partie de la chose. Sur les rails, nous utilisons Rake, les utilisateurs de C utilisent make et en Java, nous utilisons Ant et Maven. S’il est vrai que les développeurs Ant ou Maven s’occuperont peut-être mieux du développeur Java que d’autres, il y a aussi une autre question: dans quoi écrivez-vous les tâches Ant? Java. Si vous êtes un développeur Java, c’est facile.

Donc oui, une partie est d’utiliser des outils écrits dans le langage que vous utilisez.

Ant et plus tard Maven ont été conçus pour résoudre certains problèmes causés par Make (tout en en créant de nouveaux). Ce n’est que de l’évolution.

… Peu après, plusieurs projets Java open source ont réalisé que Ant pouvait résoudre les problèmes rencontrés avec Makefiles ….

De http://ant.apache.org/faq.html#history

Qu’ils résolvent n’importe quoi ou créent simplement un format supplémentaire pour apprendre est un sujet subjectif. La vérité est que c’est à peu près l’histoire de chaque nouvelle invention: le créateur dit qu’il résout beaucoup de problèmes et que les utilisateurs originaux disent que ce sont des vertus.

Le principal avantage est la possibilité d’intégrer Java.

Je suppose qu’une histoire similaire serait avec un rake par exemple.

L’un des principaux problèmes résolus par Maven (et les configurations Ant activées par Ivy) est la résolution automatisée des dépendances et le téléchargement de vos fichiers de dépendance.

Je pense que l’explication la plus probable est que plusieurs facteurs ont découragé l’utilisation de la marque au sein de la communauté Java dans une période critique (à la fin des années 1990):

  1. Étant donné que Java englobe plusieurs plates-formes, les programmeurs Java en général n’étaient pas aussi aptes aux outils Unix que les programmeurs généralement confinés à un environnement Unix (par exemple, les programmeurs C et Perl). Notez que c’est en général. Il existe sans aucun doute des programmeurs Java doués d’une compréhension approfondie d’Unix.
  2. Par conséquent, ils étaient moins habiles à la fabrication et ne savaient pas comment utiliser efficacement.
  3. Bien qu’il soit possible d’écrire un fichier Makefile court et simple qui comstack efficacement Java, une attention particulière est requirejse pour le faire de manière indépendante de la plate-forme.
  4. Par conséquent, il y avait un appétit pour un outil de construction insortingnsèquement indépendant de la plate-forme.
  5. C’est dans cet environnement que Ant et plus tard Maven ont été créés.

En bref, bien que make puisse certainement être utilisé pour des projets Java, il y a eu un moment d’opportunité pour en faire l’outil de compilation Java de facto. Ce moment est passé.

Les scripts ont tendance à dépendre de la plate-forme. Java est censé être indépendant de la plate-forme. Par conséquent, avoir un système de construction qui ne fonctionne que sur une seule plate-forme pour une firebase database multi-plateforme est un problème.

À moins que je ne sois personne, l’hypothèse selon laquelle personne ne se sert de make for java n’est pas correcte.

“Gestion de projets avec GNU Make” (disponible sous GFDL) contient un chapitre complet consacré à l’utilisation de make avec des projets Java.

Comme il contient une liste longue (et si possible juste) des avantages et des inconvénients de l’utilisation de make plutôt que d’autres outils, vous pouvez y jeter un coup d’œil. (voir: http://oreilly.com/catalog/make3/book/ )

Ant est une amélioration de la configuration XML par rapport à Makefiles et Maven est une amélioration de l’outil de génération de dépendances par rapport à Ant. Certains projets utilisent les trois. Je pense que les projets JDK utilisaient un mélange de makefiles et de ant.

Réponse courte: Parce que make n’est pas bon. Même sur le front C, de nombreuses alternatives apparaissent.

Réponse longue: make présente plusieurs failles qui le rendent peu adapté à la compilation de C, et inadapté à la compilation de Java. Vous pouvez le forcer à comstackr Java, si vous le souhaitez, mais attendez-vous à rencontrer des problèmes, dont certains ne disposent pas d’une solution ou d’une solution de contournement appropriée. Voici quelques-uns:

Résolution de dépendance

make attend de manière inhérente que les fichiers aient une dépendance de type arborescente, dans laquelle un fichier est le résultat de la construction de plusieurs autres. Cela se retourne déjà dans C en traitant les fichiers d’en-tête. make nécessite qu’un fichier include spécifique à la make soit généré pour représenter la dépendance d’un fichier C sur ses fichiers d’en-tête, donc une modification de ce dernier entraînerait la reconstruction de la version antérieure. Cependant, comme le fichier C lui-même n’est pas recréé (simplement reconstruit), make nécessite souvent de spécifier la cible sous la forme .PHONY . Heureusement, GCC prend en charge la génération automatique de ces fichiers.

En Java, la dépendance peut être circulaire et il n’y a pas d’outil pour générer automatiquement des dépendances de classes au format make . ant lieu de cela, la tâche de Depend peut lire le fichier de classe directement, déterminer les classes imscopes et supprimer le fichier de classe s’il est obsolète. Sans cela, toute dépendance non sortingviale peut vous obliger à utiliser des versions propres répétées, ce qui élimine tout avantage lié à l’utilisation d’un outil de génération.

Espaces dans les noms de fichiers

Bien que ni Java ni C n’encouragent l’utilisation d’espaces dans vos noms de fichiers de code source, cela peut poser problème même si les espaces sont dans le chemin du fichier. Considérez, par exemple, si votre code source existe dans C:\My Documents\My Code\program\src . Ce serait suffisant pour casser la make . C’est parce que make traite les noms de fichiers comme des chaînes. ant traite les chemins comme des objects spéciaux.

Analyse des fichiers pour la construction

make nécessite de définir explicitement les fichiers à construire pour chaque cible. ant permet de spécifier un dossier à parsingr automatiquement pour les fichiers sources. Cela peut sembler une commodité mineure, mais considérez qu’en Java, chaque nouvelle classe nécessite un nouveau fichier. L’ajout de fichiers au projet peut devenir très compliqué.

Et le plus gros problème avec make :

make est dépendant de POSIX

La devise de Java est “comstackr une fois partout”. Mais limiter cette compilation aux systèmes basés sur POSIX, dans lesquels le support Java est en fait le pire, n’est pas l’intention.

Les règles de construction dans make sont essentiellement de petits scripts bash . Même s’il existe un port make pour Windows, pour qu’il fonctionne correctement, il doit être fourni avec un port de bash , qui inclut une couche d’émulation POSIX pour le système de fichiers.

Cela se décline en deux variétés:

  1. MSYS qui tente de limiter la traduction POSIX aux chemins de fichiers, et peut donc avoir des pièges désagréables lors de l’exécution d’outils externes non conçus spécialement pour lui.

  2. cygwin qui fournit une émulation POSIX complète. Les programmes résultants ont cependant tendance à toujours dépendre de cette couche d’émulation.

Pour cette raison, sous Windows, l’outil de construction standard n’est pas du tout le même, mais plutôt MSBuild , qui est aussi un outil basé sur XML, plus proche en principe de ant .

En revanche, ant est construit en Java, peut être exécuté partout et contient des outils internes, appelés “tâches”, pour manipuler des fichiers et exécuter des commandes de manière indépendante de la plate-forme. Il est suffisamment polyvalent pour que vous puissiez réellement créer un programme C sous Windows en utilisant ant plutôt que make .

Et un dernier mineur:

Même les programmes C n’utilisent pas make natively

Vous ne le remarquerez peut-être pas initialement, mais les programmes C ne sont généralement pas fournis avec un Makefile . Ils sont livrés avec un CMakeLists.txt ou un script de configuration bash , qui génère le Makefile réel. En revanche, la source d’un programme Java construit à l’aide de ant est livrée avec un script ant pré-construit. Un Makefile est un produit d’autres outils. ant est autonome et traite de tout ce dont vous avez besoin pour votre processus de compilation Java, sans aucune exigence ni dépendance supplémentaire.

Lorsque vous exécutez ant sur n’importe quelle plate-forme, cela fonctionne ™. Vous ne pouvez pas obtenir ça avec make . C’est incroyablement dépendant de la plate-forme et de la configuration.

Une des principales raisons est que Ant et Maven (et la plupart des outils SCM, CI et IDE ciblés sur Java) sont écrits en Java par / pour les développeurs Java. Cela simplifie l’intégration dans votre environnement de développement et permet à d’autres outils tels que les serveurs IDE et CI d’intégrer des parties des bibliothèques ant / maven dans l’infrastructure de construction / déploiement.

Il était une fois que je travaillais sur un projet Java utilisant gmake. Mon souvenir est flou mais IIRC a eu du mal à gérer la structure des répertoires de paquets attendus par javac. Je me souviens aussi que la création de fichiers JAR était un problème à moins que vous n’ayez quelque chose de sortingvial.

Ant et Maven abordent le graphe de dépendance à la construction et sa gestion à partir d’une vue plus “moderne” … Mais comme le dit Oscar, ils ont créé leurs propres problèmes en essayant de résoudre les vieux problèmes de make.

Je n’ai jamais utilisé de projets GNU Make for Java, mais j’utilisais jmk . Malheureusement, il n’a pas été mis à jour depuis 2002.

Il possédait des fonctionnalités spécifiques à Java mais était suffisamment petit pour être intégré à votre archive source sans en augmenter considérablement la taille.

Aujourd’hui, je suppose que tout développeur Java avec lequel je partage du code a installé Ant.

ApacheAnt ne ressemble en rien à Make. Make consiste à décrire les dépendances entre les fichiers et à créer des fichiers. Ant concerne les dépendances entre les “tâches”, et est plutôt un moyen de coller des scripts de compilation.

cela peut vous aider AntVsMake