现代 Java/JVM 构建实践
现代 Java 项目正面临日益复杂的构建工具：Gradle 的灵活性和丰富插件生态，与 Maven 的简单、稳定和可预测性形成了对比。许多工程师表示，Gradle 能支持强大的增量构建和复杂工作流，但其命令式 DSL、不断变化的 API 和各种棘手边界让长期维护变得困难，因此一些人又回到了更适合企业或多团队代码库的 Maven。Bazel、Mill、Ant 以及新兴工具被视为在性能或简洁性上有潜力，但大多数人都同意：无论选择哪种构建系统，保持构建快速、统一并持续维护，才是避免技术债的关键。
Gradle vs. Maven（总体感受）
- 许多人认为 Gradle 功能强大，但灵活性也很危险：脚本几乎可以做任何事，因此容易出现“踩坑点”、跨项目风格不一致，以及难以调试的构建失败。
- 常见抱怨包括：版本之间 API 不稳定、实现同一件事有多种重叠方式、错误信息不佳，以及大型项目需要“Gradle 专家”才能维护。
- Maven 则因更简单、更可预测、长期稳定而受到称赞；今天可用的 POM，十年后大概率仍然可用。
- 几位用户描述了一条“三阶段”路径：讨厌 Maven 的僵硬 → 采用更灵活的工具（Ant/Gradle）→ 遭遇维护痛苦 → 回到 Maven。
性能与增量构建
- Gradle 因拥有合理的任务图、增量构建、测试缓存，以及在任务/插件写得正确时对大型多模块项目的良好扩展性而受到认可。
- 也有人报告 Gradle 构建不确定性强，需要手动清理，尤其是在 Android 中；并且即使是简单项目，配置阶段也被认为很慢。
- Maven 历来会在任何变化后大范围重新编译；新版本 Maven 改进了增量构建，但默认编译器行为仍然相当积极地重新编译。
- 有些用户因为习惯总是运行
clean，无意中让 Maven 变慢。
使用场景与生态压力
- 对 Android 来说，Gradle 基本是强制性的；对 Kotlin 来说也因一等支持、文档和插件生态而明显更受青睐。
- Maven 更适合那种有许多偶尔贡献者的企业式项目，因为统一性和“约定优于配置”很有价值。
- 多模块场景：Maven 支持，但可能变得笨重；如果你坚持使用大型多项目仓库，有人会建议改用 Gradle。
其他工具与方法
- Bazel 因适合 Java/monorepo、强缓存能力以及内置 uber-jar 支持而受到称赞，不过也有人觉得它更难用或对平台更敏感。
- Mill 和 Ant（配合共享导入脚本）被提及为某些团队更简单的替代方案。
- JetBrains 的 Amper 等较新的尝试（在 Gradle 之上使用 YAML）旨在简化常见的 95% 使用场景。
构建实践的普遍主题
- 不要把复杂的自定义逻辑硬塞进 Maven/Gradle；如果一个小脚本就够了，就别过度设计。
- 逐步更新构建工具、插件和依赖；被忽视的构建配置会变成重要的技术债。
- 有些人希望 Java 构建系统更声明式、更极简，但也有人指出，真实项目需要测试、代码生成、覆盖率、安全检查、打包和部署，这些都足以证明更丰富工具的合理性。