Pourquoi personne n'utilise make for Java?

Presque tous les projets Java que j'ai vus utilisent Maven ou Ant. Ce sont de bons outils et je pense que n'importe quel projet peut 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 non plus fournis avec le JDK.

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

Le problème fondamental avec Make et Java est que Make fonctionne sur le principe que vous avez spécifié une dépendance, puis une règle pour résoudre cette dépendance.

Avec le C de base, qui typiquement "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 la nuit et le jour.

Exacerbez cela avec des centaines de cours, et cela devient intenable.

Ensuite, vous combinez cela avec le fait que java a tendance à être organisé en groupes de fichiers dans des répertoires, contre 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 n'est pas non plus très efficace pour déterminer quels fichiers sont obsolètes, au niveau de la collection.

Avec Ant, il passera en revue et résumera tous les fichiers obsolètes, puis les compilera en une seule fois. Make appellera simplement le compilateur java sur chaque fichier individuel. Ne pas faire cela nécessite suffisamment d'outils externes pour vraiment montrer que Make n'est pas tout à fait à la hauteur de la tâche.

C'est pourquoi des alternatives comme Ant et Maven ont surgi.

Le vénérable makeprogramme gère assez bien les langages compilés séparément comme C et C ++. Vous compilez un module, il utilise #includepour extraire le texte d'autres fichiers d'inclusion et écrit un seul fichier objet en sortie. Le compilateur est vraiment un système un par un, avec une étape de liaison distincte pour lier les fichiers objets dans un binaire exécutable.

Cependant, en Java, le compilateur doit en fait compiler d' autres classes avec lesquelles vous importez 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 de makecréer des classes dans le bon ordre une par une, cela ne gère toujours pas 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 de celles déjà compilées. Ce type d'évaluation automatique des dépendances n'est pas vraiment possible avec makeseul.

La question se fonde sur une hypothèse erronée: un nombre non négligeable de développeurs ne utilisation make. Voir Outils de construction Java: Ant vs Maven . Quant à savoir pourquoi un développeur ne l' utiliserait pasmake : de nombreux développeurs ne l'ont jamais utilisé make, ou l'ont utilisé et l'ont détesté avec un feu qui brûle plus de mille soleils. À ce titre, 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 compiler 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. Antet Mavenpeuvent être mieux adaptés à Java qu'à make, ou comme le souligne Hank Gay, ils peuvent ne pas l'être :)

Cependant, vous avez demandé s'il était important que Ant et Maven soient écrits en Java. Bien que sur StackOverflow, nous ne considérions pas de telles pensées (fermées! Non liées à la programmation! Etc.), BIEN SÛR, CELA FAIT PARTIE DE LA CHOSE. Sur les rails, nous utilisons Rake, les mecs 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 une solution facile.

Donc oui, une partie de cela consiste à utiliser des outils écrits dans la langue que vous utilisez.

Ant et plus tard Maven ont été conçus pour résoudre certains maux de tête causés par Make(tout en en créant de nouveaux dans le processus). C'est juste une évolution.

... Peu de temps après, plusieurs projets Java open source ont réalisé qu'Ant pouvait résoudre les problèmes qu'ils avaient avec Makefiles ...

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

Qu'ils résolvent quoi que ce soit ou qu'ils 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 que cela résout beaucoup de problèmes et les utilisateurs originaux disent que ce sont des vertus.

Son principal avantage est la possibilité de s'intégrer avec java.

Je suppose qu'une histoire similaire serait avec rakepar exemple.

L'un des principaux problèmes résolus par Maven (et les configurations Ant compatibles Ivy) sur make est la résolution automatisée des dépendances et le téléchargement de vos fichiers JAR de dépendances.

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

1. Parce que Java englobe plusieurs plates-formes, les programmeurs Java en général n'étaient pas aussi compétents avec les 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. Sans aucun doute, il y a et étaient des programmeurs Java doués avec une compréhension approfondie d'Unix.
2. Par conséquent, ils étaient moins habiles à faire et ne savaient pas comment utiliser le make efficacement.
3. Bien qu'il soit possible d'écrire un Makefile court et simple qui compile Java efficacement, une attention particulière est nécessaire pour le faire d'une manière indépendante de la plate-forme.
4. Par conséquent, il y avait un appétit pour un outil de construction intrinsèquement indépendant de la plate-forme.
5. C'est dans cet environnement qu'Ant et plus tard Maven ont été créés.

En bref, si make peut très certainement être utilisé pour les projets Java, il y a eu un moment opportun pour en faire l'outil de construction Java de facto. Ce moment est passé.

Les scripts ont tendance à être intrinsèquement dépendants 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 base source multi-plate-forme est un peu un problème.

Réponse courte: parce que ce maken'est pas bon. Même sur le front C, vous voyez apparaître de nombreuses alternatives.

Réponse longue: makea plusieurs défauts qui le rendent à peine adapté à la compilation C, et inadapté du tout à la compilation Java. Vous pouvez le forcer à compiler Java, si vous le souhaitez, mais attendez-vous à rencontrer des problèmes, dont certains n'ont pas de solution ou de contournement appropriée. Voici quelques-uns:

Résolution des dépendances

makes'attend par nature à ce que les fichiers aient une dépendance semblable à une arborescence les uns sur les autres, dans lequel un fichier est le résultat de la construction de plusieurs autres. Cela se retourne déjà en C lors du traitement des fichiers d'en-tête. makenécessite qu'un makefichier d'inclusion spécifique 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 du fichier antérieur. Cependant, comme le fichier C lui-même n'est pas recréé (simplement reconstruit), make nécessite souvent de spécifier la cible comme .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 classe au makeformat. antLa Dependtâche de la tâche peut, à la place, lire directement le fichier de classe, déterminer les classes qu'elle importe et supprimer le fichier de classe si l'une d'entre elles est obsolète. Sans cela, toute dépendance non triviale peut vous obliger à utiliser des générations propres répétées, supprimant 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, makecela 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 make. En effet, makeles noms de fichiers sont traités comme des chaînes. anttraite les tracés comme des objets spéciaux.

Analyse des fichiers pour la construction

makenécessite de définir explicitement les fichiers à créer pour chaque cible. antpermet de spécifier un dossier qui doit être analysé automatiquement pour les fichiers source. 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 fastidieux.

Et le plus gros problème avec make:

make dépend de POSIX

La devise de Java est "compiler une fois exécuté 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 makesont essentiellement de petits bashscripts. Même s'il existe un port de makevers Windows, pour qu'il fonctionne correctement, il doit être associé à un port de bash, qui comprend 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 qui ne sont pas spécialement conçus pour cela.

2. cygwinqui fournit une émulation POSIX complète. Les programmes résultants, cependant, ont tendance à toujours s'appuyer sur cette couche d'émulation.

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

En revanche, il antest construit en Java, peut s'exécuter partout et contient des outils internes, appelés «tâches», pour manipuler des fichiers et exécuter des commandes d'une manière indépendante de la plate-forme. Il est suffisamment polyvalent pour que vous puissiez en fait avoir plus de facilité à créer un programme C dans Windows en utilisant antqu'avec make.

Et un dernier mineur:

Même les programmes C n'utilisent pas make nativement

Vous ne le remarquerez peut-être pas initialement, mais les programmes C ne sont généralement pas livrés avec un fichier Makefile. Ils sont livrés avec un CMakeLists.txt, ou un bashscript de configuration, qui génère le fichier réel Makefile. En revanche, la source d'un programme Java construit en utilisant antest livrée avec un antscript pré-construit. A Makefileest un produit d'autres outils - C'est à quel point il makene convient pas d'être un outil de construction à lui seul. antest autonome et traite tout ce dont vous avez besoin pour votre processus de construction Java, sans aucune exigence ou dépendance supplémentaire.

Lorsque vous exécutez antsur n'importe quelle plate-forme, cela fonctionne (tm). Vous ne pouvez pas obtenir cela avec make. Cela dépend incroyablement de la plate-forme et de la configuration.

Sauf si je ne suis personne, l'hypothèse que personne n'utilise (mal) make for java est fausse.

"Gérer des projets avec GNU Make" (disponible sous GFDL) contient un chapitre complet dédié à l'utilisation makeavec des projets java.

Comme il contient une longue liste (et j'espère juste) des avantages et des inconvénients de l'utilisation de make au lieu d'autres outils, vous voudrez peut-être y jeter un coup d'œil. (voir: http://oreilly.com/catalog/make3/book/ )

Ant est une amélioration orientée configuration XML par rapport à Makefiles et Maven est une amélioration de l'outil de création 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 fourmi.

L'une des principales raisons est que Ant et Maven (et la plupart des outils SCM, CI et IDE ciblés par 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, j'ai travaillé sur un projet Java utilisant gmake. Mon souvenir est flou mais IIRC nous avons eu du mal à gérer la structure de répertoires de paquets attendue par javac. Je me souviens également que la création de fichiers JAR était un problème à moins que vous n'ayez quelque chose de trivial.

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 en fait plus un moyen de coller des scripts de construction ensemble.

cela peut vous aider AntVsMake

Ant et Maven abordent le graphe de dépendance de build et sa gestion d'un point de vue plus «moderne» ... Mais comme le dit Oscar, ils ont créé leurs propres problèmes en essayant de résoudre les anciens problèmes avec make.

Je n'ai jamais utilisé GNU Make pour les projets Java, mais j'avais l'habitude d'utiliser jmk . Malheureusement, il n'a pas été mis à jour depuis 2002.

Il avait des fonctionnalités spécifiques à Java mais était suffisamment petit pour être inclus dans votre archive tar source sans augmenter considérablement sa taille.

De nos jours, je suppose que tout développeur Java avec lequel je partage du code a Ant installé.