为什么没有人使用 make for Java？

Why is no one using make for Java?

提问by User1

Just about every Java project that I've seen either uses Maven or Ant. They are fine tools and I think just about any project can use them. But what ever happened to make? It's used for a variety of non-Java projects and can easily handle Java. Sure you have to download make.exe if you use Windows, but Ant and Maven also don't come with the JDK.

几乎我见过的每个 Java 项目都使用 Maven 或 Ant。它们是很好的工具，我认为几乎任何项目都可以使用它们。但是，什么都发生在使？它用于各种非 Java 项目，并且可以轻松处理 Java。当然，如果你使用 Windows，你必须下载 make.exe，但是 Ant 和 Maven 也没有随 JDK 一起提供。

Is there some fundamental flaw with make when used with Java? Is it just because Ant and Maven are written in Java?

与 Java 一起使用时，make 是否存在一些基本缺陷？仅仅是因为 Ant 和 Maven 是用 Java 编写的吗？

采纳答案by Will Hartung

The fundamental issue with Make and Java is that Make works on the premise that you have specify a dependency, and then a rule to resolve that dependency.

Make 和 Java 的基本问题是 Make 工作的前提是您指定了依赖项，然后是解决该依赖项的规则。

With basic C, that typically "to convert a main.c file to a main.o file, run "cc main.c".

使用基本的 C，通常“将 main.c 文件转换为 main.o 文件，运行“cc main.c”。

You can do that in java, but you quickly learn something.

你可以在java中做到这一点，但你很快就会学到一些东西。

Mostly that the javac compiler is slow to start up.

主要是 javac 编译器启动缓慢。

The difference between:

和...之间的不同：

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

and

和

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

is night and day.

是白天和黑夜。

Exacerbate that with hundreds of classes, and it just becomes untenable.

用数百个类加剧这种情况，它就会变得站不住脚。

Then you combine that with the fact that java tends to be organized as groups of files in directories, vs C and others which tend towards a flatter structure. Make doesn't have much direct support to working with hierarchies of files.

然后你将它与 java 倾向于在目录中组织为文件组的事实相结合，而 C 和其他倾向于更扁平的结构。Make 对处理文件层次结构没有太多直接支持。

Make also isn't very good at determining what files are out of date, at a collection level.

Make 也不太擅长在集合级别确定哪些文件已过期。

With Ant, it will go through and sum up all of the files that are out of date, and then compile them in one go. Make will simply call the java compiler on each individual file. Having make NOT do this requires enough external tooling to really show that Make is not quite up to the task.

使用Ant，它会遍历并总结所有过时的文件，然后一次性编译它们。Make 将简单地在每个单独的文件上调用 java 编译器。让 make NOT 做到这一点需要足够的外部工具来真正表明 Make 不能胜任这项任务。

That's why alternatives like Ant and Maven rose up.

这就是像 Ant 和 Maven 这样的替代品兴起的原因。

回答by OscarRyz

Ant and later Maven were designed to solve some headaches caused by Make( while creating new ones in the process ) It is just evolution.

Ant 和后来的 Maven 旨在解决由Make（同时在过程中创建新的）引起的一些头痛，这只是进化。

...Soon thereafter, several open source Java projects realized that Ant could solve the problems they had with Makefiles....

...此后不久，几个开源 Java 项目意识到 Ant 可以解决他们使用 Makefile 遇到的问题....

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

来自http://ant.apache.org/faq.html#history

Whether they solve anything or just create an extra format to learn is a subjective topic. The truth is that's pretty much the history of every new invention: The creator says it solves a lot of problems and the original users say those are virtues.

他们是否解决任何问题或只是创建一个额外的格式来学习是一个主观的话题。事实是，这几乎是每一项新发明的历史：创造者说它解决了很多问题，而原始用户说这些都是优点。

The main advantage it has, is the possibility to integrate with java.

它的主要优点是可以与 java 集成。

I guess a similar history would be with rakefor instance.

例如，我想类似的历史会发生rake。

回答by Greg Hewgill

The venerable makeprogram handles separately compiled languages like C and C++ reasonably well. You compile a module, it uses #includeto pull in the text of other include files, and writes a single object file as output. The compiler is very much a one-at-a-time system, with a separate linking step to bind the object files into an executable binary.

这个古老的make程序可以很好地处理单独编译的语言，如 C 和 C++。您编译一个模块，它用于#include拉入其他包含文件的文本，并写入单个目标文件作为输出。编译器在很大程度上是一个一次一个系统，有一个单独的链接步骤将目标文件绑定到一个可执行的二进制文件中。

However, in Java, the compiler has to actually compileother classes that you import with import. Although it would be possible to write something that generated all the necessary dependencies from Java source code, so that makewould build classes in the correct order one at a time, this still wouldn't handle cases such as circular dependencies.

但是，在 Java 中，编译器必须实际编译您使用import. 尽管可以编写一些从 Java 源代码生成所有必要依赖项的东西，make以便一次一个地以正确的顺序构建类，但这仍然无法处理诸如循环依赖项之类的情况。

The Java compiler can also be more efficient by caching the compiled results of other classes while compiling further classes that depend on the results of ones already compiled. This sort of automatic dependency evaluation is not really possible with makealone.

通过缓存其他类的编译结果，同时编译依赖于已编译结果的其他类，Java 编译器也可以提高效率。make单独使用这种自动依赖性评估是不可能的。

回答by John Weldon

Ant and Maven approach the build dependency graph and the management of it from a more 'modern' view... But as Oscar says, they created their own problems while attempting to address the old problems with make.

Ant 和 Maven 从更“现代”的角度处理构建依赖关系图及其管理……但正如 Oscar 所说，他们在尝试解决 make 的旧问题时创造了自己的问题。

回答by Ophidian

One of the major issues solved by Maven (and Ivy-enabled Ant setups) over make is automated dependency resolution and downloading of your dependency jars.

Maven（和支持 Ivy 的 Ant 设置）通过 make 解决的主要问题之一是自动依赖项解析和下载您的依赖项 jar。

回答by Hank Gay

The question is based on an incorrect assumption: a non-trivial number of developers douse make. See Java Build Tools: Ant vs. Maven. As for why a developer wouldn'tuse make: many developers either have never used make, or used it and hated it with a fire that burns hotter than a thousand suns. As such, they use alternative tools.

这个问题基于一个错误的假设：确实有相当多的开发人员使用make. 请参阅Java 构建工具：Ant 与 Maven。至于为什么开发人员不会使用make：许多开发人员要么从未使用过make，要么使用它并且讨厌它，就像燃烧的火比一千个太阳还要热。因此，他们使用替代工具。

回答by Dan Rosenstark

All the other answers about the technical merits of each are true. Antand Mavenmay be better suited to Java than make, or as Hank Gay points out, they may not :)

关于每个技术优点的所有其他答案都是正确的。Ant并且Maven可能比 make 更适合 Java，或者正如 Hank Gay 指出的那样，它们可能不:)

However, you asked if it matters that Ant and Maven are written in Java. Although on StackOverflow we don't consider such thoughts (closed! not-programming-related! etc.), OF COURSE THAT'S PART OF THE THING. On rails we use Rake, C dudes use make, and in Java we use Ant and Maven. While it's true that the Ant or Maven developers will look after the Java developer perhaps better than others, there's also another question: what do you write Ant tasks in? Java. If you're a Java developer, that's an easy fit.

但是，您询问 Ant 和 Maven 是用 Java 编写的是否重要。尽管在 StackOverflow 上我们不考虑这样的想法（关闭！与编程无关！等），当然这是事情的一部分。在 Rails 上我们使用 Rake，C 语言使用 make，在 Java 中我们使用 Ant 和 Maven。虽然 Ant 或 Maven 开发人员确实会比其他人更好地照顾 Java 开发人员，但还有另一个问题：你用什么编写 Ant 任务？爪哇。如果您是 Java 开发人员，那么这很容易。

So yeah, part of it is to use tools written in the language you are tooling.

所以是的，部分原因是使用以您正在使用的语言编写的工具。

回答by finnw

I've never used GNU Make for Java projects, but I used to use jmk. Sadly it hasn't been updated since 2002.

我从未将 GNU Make 用于 Java 项目，但我曾经使用过jmk。遗憾的是，它自 2002 年以来就没有更新过。

It had some Java-specific functionality but was small enough to include in your source tarball without significantly increasing its size.

它具有一些特定于 Java 的功能，但足够小，可以包含在源 tarball 中，而不会显着增加其大小。

Nowadays I just assume any Java developer I share code with has Ant installed.

现在，我只是假设与我共享代码的任何 Java 开发人员都安装了 Ant。

回答by Chris Nava

One big reason is that both Ant and Maven (and most java targeted SCM, CI and IDE tools) are written in java by/for java developers. This makes it simpler to integrate into your development environment and allows other tools such as the IDE and CI servers to integrate portions of the ant/maven libraries within the build/deployment infrastructure.

一个重要的原因是 Ant 和 Maven（以及大多数面向 Java 的 SCM、CI 和 IDE 工具）都是由 Java 开发人员/为 Java 开发人员用 Java 编写的。这使得集成到您的开发环境中变得更加简单，并允许其他工具（例如 IDE 和 CI 服务器）在构建/部署基础架构中集成部分 ant/maven 库。

回答by Brian Fox

Make scripts tend to be inherently platform dependent. Java is supposed to be platform independent. Therefore having a build system that only works on one platform for a multi-platform sourcebase is kindof a problem.

使脚本倾向于固有的平台相关性。Java 应该是平台独立的。因此，对于多平台源库，拥有一个只能在一个平台上运行的构建系统是一个问题。