The JDK contains a set of foundation tools 1 but none of them guides
developers from processing Java source files into shippable products: be it a
reusable modular JAR file with its API documentation or an entire custom (soon
static 2) runtime image. There exists an implicit workflow encoded in the
available options of the foundation tools. The (binary) output of one tool is
the input of one or more tools. With the introduction of modules in Java 9 some
structural parts of that workflow got a) promoted into the language itself and
b) resulted in explicit module-related tool options.
These structural information, encoded explicitly by developers in Java's module
descriptors, can be used as basic building blocks when describing a modular
Java project. I think of it as a "project-info.java" file -- which I don't
propose to introduce (as a part of the language) -- but it helps to transport
the basic idea. With assets from the "Greetings world" example 3 a
fictitious project descriptor could read like:
project greet {
version 1-ea;
modules com.greetings,org.astro;
main-module com.greetings;
module com.greetings {
main-class com.greetings.Main;
}
}
Based on such a project descriptor Bach calls existing (and future) JDK
tools in the right order with the right arguments. Nothing more, nothing less.