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.