Why isn't java used as a build language?

Java is an imperative language, Ant, Maven, etc. are declarative languages:

We could define the difference as follows:

• Imperative programming: telling the "machine" how to do something, and as a result what you want to happen will happen.
• Declarative programming: telling the "machine" what you would like to happen, and let the computer figure out how to do it.¹

Build languages tell the builder what should be done, from where it should be taken, etc. The engine which runs the build (which is written in an imperative language, like @ElliottFrisch has noted), reads these instructions, and fulfills them.

Declarative languages may seem more appropriate in build scenarios, since build tasks are generally the same all over, and it is considered more maintainable and readable in that form than in full-fledged code form.

Specific Tool for a Specific Purpose

• Verbosity

  General purpose languages are often too verbose. If I had to manage a build in Java, I'd be very depressed very quickly by the size of the beast. However, it could easily be manageable using a DSL written in Java. And to some extent that's how you can see Gradle (for Groovy) and Buildr (for Ruby).

• Difficulty

  General purpose languages are hard. Well I don't think programming is hard and can't be picked up by anyone, but the point is: your build engineer isn't necessarily your programmer!

• Purpose

  That's more or less at the intersection of difficulty and verbosity. A language is designed for a purpose, and here we're talking about something very specific. So why would you need or want to use a general purpose language? For builds, you need:

  • branches and conditionals to handle separate configurations, environments, etc...
  • a set of instructions to extract data from your environment,
  • a set of instructions to produce deliverables.

  You don't really need much more.

Sure it's annoying when your build system seems like it's not flexible enough for that one special use case you're after, but it's probably far better than the alternative for most people.

That's probably why there's a polarity between people who prefer declarative build systems over most programmable onces: I guess a developer might have a natural tendency to look for ways to break out of the box.

Wait, Do We Really Need a Tool?

Another related question would be: do we really need a build tool? Isn't the fact that they exist in all languages the sign that they fill a gap that shouldn't even be there in the first place?

Some languages don't necessarily require a build tool. For instance, most scripting languages don't need one and resolve at load time. Or take Go, whose compiler will handle everything for you, which is a nice counterpoint: what if a compiler like gcc suddenly didn't need a bunch of flags, a linker, and a makefile to die everything together? Or if javac didn't need a build.xml or pom.xml to tell him what to do? Shouldn't dependency management directly be part of the language's own tooling, as the dependencies are a part of the final program?

It surely seems like a much simpler approach for the user (the builder). Though one could argue they're just doing in under the hood and taking away your choice and opportunities to influence that build process (but then you'd hope such a tool allows compiler extensions and similar things). Plus we used to see the tools and the language as two separate things, so he might seem unpure to suddenly have them so tightly coupled.

I don't think the language you use to build your programs is sthe issue. It's the language you use to program and its core platform and tooling that should matter, and we're still making headway on that.

Personally, I've used make/gmake/autotools/pmk and been happy with them for C, and I started with Java when all we had was make, then ant, and now I'm generally preferring Maven over all these alternatives. Though I can see value in gradle, buildr and others, but I like the prevalence of maven so far, until a more significant shift occurs. Plus I like that it's rigid, but still leaves you the ability to work around that if necessary. That it's not easy is a good thing.

It's a build tool. Just learn to embrace it and don't fight it. It's a losing battle. Or at least a very very long one.

If you look at the features of a typical build system you find:

1. Lots of data: names, switches, settings, configuration items, strings, etc
2. Lots of interaction with the environment: commands, environment variables
3. A relatively straightforward "build engine" handling dependencies, threading, logging etc.

If you set out to write a series of build files using some language (Java/C#/Python/etc), by about the third or fourth iteration you would settle on (a) keeping most of the data and external commands as data in something like XML (b) writing the "build engine" in your favorite language.

You would also find it useful to treat some of the data in your XML as an interpreted language, to trigger various features in the build engine. You might also interpret some macros or perform string substitutions, in the data.

In other words, you would finish up with Make, or Ant, or Rake, or MsBuild. An imperative language for the things it does well, and data structures to describe what you want to do, now usually in XML.

A number of factors count against using Java/C++/C# in these cases.

Firstly, you'd have to compile your build script before you could run it to build your app. How would you specify any packages, flags, compiler versions, tool paths needed to build your build script? Certainly, you could come up with a way around it, but its much more straightforward to have either have a language that doesn't need that build step (e.g. python) or a language that your build tool natively understands.

Secondly, build files are data heavy whereas Java/C++/C# are much more geared towards writing code and algorithms. Java and friends don't have a very succinct representation of all the data you'd want to store.

Thirdly, Java and friends need a lot of boilerplate to be valid. The build file would have to be inside a method inside a class with all of its imports. When using a scripting language or custom language you can avoid all that boilerplate and just have the build details themselves.

Well, technically it is. Ant and Maven are written in java. Basically you're asking "Why would anybody write code that abstracts implementation details?" Or, more succinctly, what is the purpose of a Domain Specific Language?

The short answer is: because there's a very defined process that projects go through called "a build" -- it's where we accumulate code, compile it, put it into packages, and often generate metrics and run unit tests. Rather than using a general purpose language to support his process, we use a tool that is geared toward those specific goals.

Why should I have to think about "Open a file, read it, parse it using an EBNF tree, do transformation of the parsed node tree into an output file using a visitor pattern, close the file" when I can think "compile this".