Почему никто не использует make для Java?

Ответ 1

Основная проблема с Make и Java заключается в том, что Make работает в предпосылке, что вы указали зависимость, а затем - для разрешения этой зависимости.

С базовым C, который обычно "преобразует файл main.c в файл main.o, запустите" cc main.c ".

Вы можете сделать это в java, но вы быстро узнаете что-то.

В основном, компилятор javac не запускается.

Разница между:

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

и

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

- ночь и день.

Обострите это на сотни классов, и оно просто становится несостоятельным.

Затем вы комбинируете это с тем фактом, что java имеет тенденцию быть организован как группы файлов в каталогах, vs C и другие, которые имеют тенденцию к более плоской структуре. Make не имеет непосредственной поддержки для работы с иерархиями файлов.

Сделайте также не очень хорошо, чтобы определить, какие файлы устарели, на уровне коллекции.

С Ant он будет проходить и суммировать все устаревшие файлы, а затем скомпилировать их за один раз. Make будет просто вызывать java-компилятор для каждого отдельного файла. Не делая этого, для этого требуется достаточно внешних инструментов, чтобы действительно показать, что Make не совсем подходит к задаче.

Вот почему такие альтернативы, как Ant и Maven, поднялись.

Ответ 2

Достоверная программа make обрабатывает отдельно скомпилированные языки, такие как C и С++, достаточно хорошо. Вы компилируете модуль, он использует #include, чтобы вытащить текст других включенных файлов и записывает один файл объекта в качестве вывода. Компилятор - это очень простая система с отдельным шагом привязки для привязки объектных файлов к исполняемому двоичному файлу.

Однако в Java компилятор должен фактически скомпилировать другие классы, которые вы импортируете с помощью import. Хотя можно было бы написать что-то, что сгенерировало все необходимые зависимости от исходного кода Java, так что make будет строить классы в правильном порядке по одному, это все равно не будет обрабатывать такие случаи, как круговые зависимости.

Компилятор Java также может быть более эффективным, кэшируя скомпилированные результаты других классов при компиляции других классов, которые зависят от результатов уже скомпилированных. Такая автоматическая оценка зависимостей невозможна только с make.

Ответ 3

Вопрос основан на неправильном предположении: нетривиальное число разработчиков использует make. См. Java Build Tools: Ant против Maven. Что касается того, почему разработчик не использовал make: многие разработчики либо никогда не использовали make, либо использовали его, и ненавидели его огнем, который горит горячее, чем тысяча солнц. Таким образом, они используют альтернативные инструменты.

Ответ 4

Все остальные ответы о технических достоинствах каждого из них верны. Ant и Maven могут быть лучше подходят для Java, чем make, или, как указывает Хэнк Гей, они могут не:)

Однако вы спросили, имеет ли значение, что Ant и Maven написаны на Java. Хотя на StackOverflow мы не рассматриваем такие мысли (закрытые! Не связанные с программированием! И т.д.), КУРС, ЧТО ЧАСТЬ ВЕЩИ. На рельсах мы используем Rake, C dudes use make, а на Java мы используем Ant и Maven. Хотя верно, что разработчики Ant или Maven будут следить за тем, что разработчик Java, возможно, лучше других, возникает еще один вопрос: что вы пишете в Ant задачи? Ява. Если вы разработчик Java, это легко подгоняется.

Итак, да, часть из них заключается в использовании инструментов, написанных на языке, который вы используете.

Ответ 5

Фактически make может обрабатывать перекомпиляцию в одной команде из всех устаревших java файлов. Измените первую строку, если вы не хотите скомпилировать все файлы в каталоге или хотите получить определенный порядок...

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+=$$<)

Ответ 6

Ant, а позже Maven были разработаны для решения некоторых головных болей, вызванных Make (при создании новых в процессе). Это просто эволюция.

... Вскоре после этого несколько проектов Java с открытым исходным кодом поняли, что Ant может решить проблемы, которые у них были с Makefile....

От http://ant.apache.org/faq.html#history

Решают ли они что-либо или просто создают дополнительный формат для изучения, это субъективная тема. Правда в том, что в значительной степени история каждого нового изобретения: создатель говорит, что он решает множество проблем, и оригинальные пользователи говорят, что это добродетели.

Основным преимуществом, которое он имеет, является возможность интеграции с java.

Я думаю, что подобная история была бы с rake, например.

Ответ 7

Одной из основных проблем, решаемых Maven (и настройками Ant с поддержкой Ivy) над make, является автоматическое разрешение зависимостей и загрузка ваших банок зависимости.

Ответ 8

Я думаю, что наиболее вероятным объяснением является то, что несколько факторов не поощряли использование make в сообществе Java в критический период времени (конец 1990-х годов):

• Поскольку Java включает в себя несколько платформ, Java-программисты в целом не были такими же умелыми инструментами Unix, как и программисты, обычно ограничивающиеся средой Unix (например, программисты C и Perl). Обратите внимание, что это В ОБЩЕМ. Несомненно, есть и были одаренными программистами Java с глубоким пониманием Unix.
• Следовательно, они были менее искусны в изготовлении и не знали, как эффективно использовать make.
• В то время как можно написать короткий и простой Makefile, который скомпилирует Java эффективно, для этого требуется особая осторожность независимым от платформы способом.
• Следовательно, появился аппетит для встроенного в платформу инструмента сборки.
• Именно в этой среде были созданы Ant и более поздние Maven.

Короче говоря, в то время как, безусловно, можно использовать для проектов Java, был момент возможности сделать его де-факто инструментом Java-сборки. Этот момент прошел.

Ответ 9

Сценарии обычно зависят от платформы. Предполагается, что Java не зависит от платформы. Поэтому наличие системы сборки, которая работает только на одной платформе для многоплатформенной базы данных, является проблемой.

Ответ 10

Если я не один, то предположение, что никто не ошибается, использует make для java.

"Управление проектами с помощью GNU Make" (доступно под GFDL) содержит полную главу, посвященную использованию make с java-проектами.

Как он содержит длинный (и, надеюсь, справедливый) список плюсов и минусов использования make вместо других инструментов, которые вы можете посмотреть там. (см. http://oreilly.com/catalog/make3/book/)

Ответ 11

Ant - это улучшение, ориентированное на конфигурацию XML по сравнению с Makefiles, а Maven - усовершенствование инструмента построения зависимостей над Ant. Некоторые проекты используют все три. Я думаю, что в проектах JDK использовалось сочетание make файлов и Ant.

Ответ 12

Короткий ответ: Потому что make не очень хорошо. Даже на фронте C вы видите много альтернатив, которые появляются.

Длинный ответ: make имеет несколько недостатков, которые делают его едва пригодным для компиляции C и непригодны для компиляции Java. Вы можете заставить его скомпилировать Java, если хотите, но ожидаете столкнуться с проблемами, некоторые из которых не имеют подходящего решения или обходного пути. Вот несколько:

Разрешение зависимостей

make по своей сути ожидает, что файлы имеют древовидную зависимость друг от друга, в которой один файл является результатом создания нескольких других. Это уже приводит к ошибкам в C при работе с файлами заголовков. make требует создания make -специфического файла include, который будет сгенерирован для представления зависимости файла C от файлов заголовков, поэтому изменение последнего приведет к тому, что ранее будет восстановлен. Однако, поскольку сам файл C не воссоздан (просто перестроен), часто требуется указать цель как .PHONY. К счастью, GCC поддерживает автоматическое создание этих файлов.

В Java зависимость может быть круговой, и нет инструмента для автоматического генерации зависимостей класса в формате make. ant Depend задача может вместо этого напрямую прочитать файл класса, определить, какие классы он импортирует, и удалить файл класса, если какой-либо из них устарел. Без этого любая нетривиальная зависимость может привести к тому, что вы будете вынуждены использовать повторяющиеся чистые сборки, удалив все преимущества использования инструмента построения.

Пробелы в именах файлов

Хотя ни Java, ни C не поощряют использование пробелов в именах файлов исходного кода, в make это может быть проблемой, даже если пробелы находятся в пути к файлу. Рассмотрим, например, если ваш исходный код существует в C:\My Documents\My Code\program\src. Этого было бы достаточно, чтобы сломать make. Это связано с тем, что make обрабатывает имена файлов как строки. ant рассматривает пути как специальные объекты.

Сканирование файлов для сборки

make требуется явно указать, какие файлы должны быть созданы для каждой цели. ant позволяет указать папку, которая будет автоматически сканироваться для исходных файлов. Это может показаться незначительным, но учтите, что в Java каждому новому классу требуется новый файл. Добавление файлов в проект может стать большой проблемой быстро.

И самая большая проблема с make:

make является зависимым от POSIX

Java-девиз "компилируется, когда он выполняется везде". Но ограничение этой компиляции на POSIX-системы, в которых поддержка Java на самом деле является наихудшей, не является намерением.

Правила сборки в make являются по существу небольшими сценариями bash. Несмотря на то, что для Windows есть порт make, чтобы он работал правильно, он должен быть связан с портом bash, который включает в себя слой эмуляции POSIX для файловой системы.

Это происходит в двух вариантах:

• MSYS, который пытается ограничить перевод POSIX в пути к файлам и поэтому может иметь неприятные ошибки при запуске внешних инструментов, специально не созданных для него.

• cygwin, который обеспечивает полную эмуляцию POSIX. Однако полученные программы, как правило, все еще полагаются на этот уровень эмуляции.

По этой причине в Windows стандартный инструмент построения вообще не является make, а скорее MSBuild, который также является инструментом на основе XML, в принципе ближе к ant.

В отличие от этого, ant встроен в Java, может работать повсюду и содержит внутренние инструменты, называемые "задачи", для управления файлами и выполнения команд независимым от платформы способом. Это достаточно универсально, что вы можете на самом деле легче создавать C-программу в Windows с помощью ant, чем использовать make.

И один последний второстепенный:

Даже программы C не используют make изначально

Вы не можете изначально заметить это, но программы C обычно не поставляются с Makefile. Они поставляются с конфигурацией CMakeLists.txt или bash script, которая генерирует фактический Makefile. Напротив, исходный код Java-программы, построенной с использованием ant, поставляется с предварительно созданным ant script. A Makefile является продуктом других инструментов. Насколько make не подходит для самостоятельной сборки. ant является автономным и имеет дело со всем, что вам нужно для процесса сборки Java, без каких-либо дополнительных требований или зависимостей.

Когда вы запускаете ant на любой платформе, это Just Works (tm). Вы не можете получить это с помощью make. Это невероятно зависит от платформы и конфигурации.

Ответ 13

Одна большая причина заключается в том, что как Ant, так и Maven (и большинство java-ориентированных инструментов SCM, CI и IDE) записываются в java с помощью/для разработчиков Java. Это упрощает интеграцию в среду разработки и позволяет другим инструментам, таким как серверы IDE и CI, интегрировать части библиотек ant/maven в инфраструктуру сборки/развертывания.

Ответ 14

Когда-то я работал над проектом Java, который использовал gmake. Мое воспоминание туманно, но IIRC мы с трудом справлялись с структурой каталогов пакетов, которую ожидает javac. Я также помню, что создание JAR файлов было затруднительным, если у вас не было чего-то тривиального.

Ответ 15

Ant, а Maven подходит к графику зависимости сборки и управлению им из более "современного" представления... Но, как говорит Оскар, они создали свои собственные проблемы, пытаясь решить старые проблемы с make.

Ответ 16

Я никогда не использовал GNU Make для проектов Java, но использовал jmk. К сожалению, он не обновлялся с 2002 года.

У него была определенная Java-функция, но была достаточно мала, чтобы включать в исходный архив без существенного увеличения его размера.

В настоящее время я просто предполагаю, что любой разработчик Java, с которым я обмениваюсь кодом, имеет Ant.

Ответ 17

ApacheAnt не похож на Make. Make - это описание зависимостей между файлами и способ сборки файлов. Ant относится к зависимостям между "задачами" и, в действительности, больше подходит для склеивания скриптов сборки.

это может помочь вам AntVsMake