Greetings All, "An In-depth Look at Gradle's Approach to Faster Compilation" has the following footnote:

Assuming a non-JPMS build, which may affect certain details.

Does modularizing a build have any known performance impacts, positive or negative? For example, might module descriptor info be used to speed up ABI analysis for compilation avoidance when only a subset of the packages containing public API in a project are exported? Does

java.modularity.inferModulePath

add any significant overhead?

> For example, might module descriptor info be used to speed up ABI analysis for compilation avoidance when only a subset of the packages containing public API in a project are exported? We don't have any special logic on incremental compilation side to use module descriptor info for faster compilation. So modules should not affect compilation performance in a positive or a negative way. > Does

java.modularity.inferModulePath

add any significant overhead? I don't expect there is any penalty, but we never really measured it. But I know that there could be problems with incremental compilation if you have multiple modules per project, e.g.:

src/main/java/my.module.first/module-info.java
src/main/java/my.module.second/module-info.java

In that case you might need to disable incremental compilation, while compilation avoidance still works

Thanks for the info. Much appreciated. It’s good to know there aren’t any known general performance concerns with modularization. I wouldn’t foresee putting multiple modules in a single project, except for blackbox integration tests in a separate corresponding source set (e.g. 'src/integrationTest/java’). Would that impact incremental compilation in any way?

Integration tests are compiled with a separate task in that case, so it's not a problem