It's astonishing how many people see that both build tool config (e.g. pom.xml) and module declaration (module-info.java) list dependencies and then jump to the conclusion that one should be continuously generated from the other. This is a bad idea for a few reasons. 🧵
1. Build tool config and module declaration contain lots of information that the other couldn't care less about (e.g. module exports and services are meaningless to build tools). So to generate, you need to put a lot of information in a place, where it's useless.
2. The reason for that is that build tools and module system serve *very* different purposes. Tasking one with generating the config for the other is a superb example for coupling mostly unrelated responsibilities. We know where that leads.
3. Letting build tools generate declarations isn't as trivial as it sounds (sitepoint.com/maven-cannot-g…). It would also need to be reimplemented by every build tool and IDE/build tool integration (or do you want to run our build tool, every time you add an `exports`?).
4. Speaking of IDEs, to get IDE support for editing module declarations, they would have to understand what part of each build tools' config contains the modules part. More effort duplicated across different projects.
5. All of that would add a considerable amount of complexity to an already challenging problem (modularity) and a non-trivial technical system (Java module system). More places for bugs to hide and more opportunities to misunderstand and get lost.
6. Having an auto-generated declaration makes it much less likely that you benefit from one of the biggest benefits of modules: Using a single-source-file description of your entire (sub)project. medium.com/97-things/take…
That's just the first half dozen off the top of my head. I'm sure there are more. And in case you're limiting the proposal to partial generation ("just the ~t̶i̶p̶~ `requires` directives"), 3.-6. apply there as well (to a lesser degree).
And all of that for what? IDEs make it as easy as hitting a key combo to add a `requires` to a module declaration. Asking build tools and IDEs to solve non-trivial problems and users to understand a third layer of complexity seems overkill for sparing a few keystrokes. </rant>
NB: This is unrelated to generating an initial module-info.java for an existing project. That's a perfectly fine approach to start creating Java modules, assuming you carefully check and groom the tool's output.
@nipafx Very well described. That is exactly why I explain modules without Maven or Gradle, just javac and java. To show, that they are orthogonal most of the time and have a different purpose.