hengyunabc

工程大了，单测多了必然会变慢，这个没啥办法。

可以考虑把单测并发执行，但这个对代码有一点要求。

还有一种办法是把集成测试和单测分开。单测用 surefire 插件，集成测试用 maven-failsafe-plugin 插件。

看起来 LZ 是想要在不同的分支里随意切换，不同的分支里，可能有不同的 maven module 。

1. 切换失败，这个是 IDEA 的锅，这个和 maven 本身没啥关系。试想一个工程，不断的切换分支，不断的增加/删除 maven module ，这个是一个很复杂的问题，IDEA 也不可能做到完美。仔细想想里面各种加速的缓存，你要是 IDEA 的开发，可能也会觉得非常的头疼。
2. IDEA 就是有可能出现各种问题，所以不时可以重启一下。或者多数情况下，用命令行执行 `mvn compile` 。这样子能保证大部分情况下是正常的。
3. 可以用 mvnd : https://github.com/apache/maven-mvnd ，这个可以大大加速 maven 的编译
4. 如果是要不断切换分支，我建议是直接两个仓库，一个仓库一个分支，这样子不会有问题。还有一种办法是用 git worktree ，但这个用起来比较麻烦。
5. 在 maven 3.5.0 之后，直接支持了 ${revision} 的概念，不需要配置任何插件，直接全部 pom.xml ，只有一个地方控制版本号。https://maven.apache.org/maven-ci-friendly.html

所有的开源项目都要看背后的商业公司。gradle 是基于 groovy 开发的，groovy 已经被证明是一个没啥前途的项目。gradle 出来很多年使用率都一般，后面被 Android 出来拉了一把。因为 Android 的打包太复杂了，需要 gralde 才能比较好配置。
后面 gradle 支持 kotlin 配置，又拉了一把。

升个高版本点的 spring boot 应该可以解决，它会保存依赖 jar 的顺序，避免不同环境加载 jar 顺序不一致。

java module 不太可能被太规模应用在业务系统里。它设计之初就是为了 jdk 本身拆分的，它也比较好的完成了这个任务。后面出现的 jlink, jpackage 尽管好像没有太规模应用起来，但应用可以很轻松打包出一个自己的轻量化 jdk 了。

比如这个： https://github.com/hengyunabc/lite-jdk

为了兼容，不同版本的 jdk 对于 unnamed module 的访问控制不一样，是慢慢收紧的。jdk 9/11 ，应该是 unnamed module 还可以反射访问 jdk 内部的模块。只会打印出提示信息。

在 jdk 17 之后，反射访问 jdk 内部模块是直接非法的。

这个工具可以运行时动态打开 jdk 的 module ，可以减少一些 export/open 的 jvm 参数配置： https://github.com/hengyunabc/jpms-tools

spring boot 其实自带一套 service 机制，jar 本身就是一个脚本，打包时配置下就好： https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#deployment.installing

原理： https://hengyun.tech/spring-boot-executable-jar/

😂，开发者来回答下这个。
本质上是 Arthas 的能力太强，理论上你可以随意暴力搜索对象，随意函数调用。这把锋利的工具产生的后果取决于使用的人。
上面提到的 issue 有很清楚的说明： https://github.com/alibaba/arthas/issues/44#issuecomment-569007710

我来说下根本原因吧，msgpack 是日本公司发明的，作者一并写了很多的库，比如 Fluentd ，但人力终有限，msgpack 的多语言实现也一般。当年 redis 作者推过一把。
本质上大部分后来的开源软件都要有商业公司背书，没有金钱的支持是玩不转的。

可以试下 arthas vmtool ，https://arthas.aliyun.com/doc/vmtool