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

Почти каждый Java-проект, который я видел, использует Maven или Ant. Они прекрасные инструменты, и я думаю, что любой проект может использовать их. Но что же случилось с делать ? Он используется для различных не-Java проектов и может легко обрабатывать Java. Конечно, вам нужно скачать make.exe, если вы используете Windows, но Ant и Maven также не поставляются с JDK.

Есть ли какой-то фундаментальный недостаток в make при использовании с Java? Это только потому, что Ant и Maven написаны на Java?

Основная проблема 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 имеет тенденцию организовываться как группы файлов в каталогах, против C и других, которые имеют тенденцию к более плоской структуре. Make не имеет прямой поддержки для работы с иерархиями файлов.

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

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

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

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

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

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

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

Фактически, 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+=$$<)

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

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

Так что да, отчасти это использование инструментов, написанных на том языке, на котором вы работаете.

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

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

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

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

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

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

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

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

1. Поскольку Java охватывает несколько платформ, программисты на Java в целом не были настолько хороши в инструментах Unix, как программисты, как правило, ограниченные средой Unix (например, программисты на C и Perl). Обратите внимание, что это в общем. Без сомнения, есть и были одаренные программисты на Java с глубоким пониманием Unix.
2. Следовательно, они были менее искусны в make и не знали, как эффективно использовать make.
3. В то время как можно написать короткий и простой Makefile, который эффективно компилирует Java, требуется дополнительная осторожность, не зависящая от платформы.
4. Следовательно, был аппетит к изначально независимому от платформы инструменту сборки.
5. Именно в этой среде были созданы Ant и позже Maven.

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

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

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

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

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

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

В Java зависимость может быть круговой, и в ней нет инструмента для автоматического создания зависимостей классов. make формате. ant«S 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скриптами. Несмотря на наличие порта makeдля Windows, для правильной работы он должен быть связан с портом bash, который включает в себя уровень эмуляции POSIX для файловой системы.

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

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

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

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

Напротив, antон построен на Java, может работать везде и содержит внутренние инструменты, называемые «задачами», для манипулирования файлами и выполнения команд независимо от платформы. Он достаточно универсален, так что вы можете на самом деле легче создавать C-программу в Windows, antчем использовать make.

И последний минор:

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

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

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

Если я не являюсь никем, предположение, что никто не (неправильно) использует make для java, неверно.

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

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

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

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

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

ApacheAnt не похож на Make. Make рассказывает о зависимости между файлами и о том, как создавать файлы. Ant посвящен зависимостям между «задачами» и представляет собой скорее способ склеивания сценариев сборки.

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

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

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

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

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