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

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

还有一种办法是把集成测试和单测分开。单测用 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

spring boot 最好是把 endpoint 配置为单独的端口，不对外暴露。官方在 actuator 上总是各种打补丁，独立端口才是最优解。

所以拿到 npm 项目，第一时间把版本号全改为固定的，不然过几个月还能不能 build 就看烧高香了。

没有办法理解为什么 npm 这么喜欢所谓的版本自动升级，这个不是把性命交别人手上么。

@lululau 没有太理解。是否使用 arthas，使用哪个命令，对用户来说本身就是自己做的选择。

@young1lin
可以在公众号里加我微信，欢迎投递简历 :)

@lululau 有几个影响。
1. ClassLoader 可能会有泄露，比如 groovy 就很多版本都有问题
2. arthas 目前要支持 jdk6
3. 这些语言体积通常比较大，使 arthas 本身体积增大
4. 会对 jvm 本身 meta space 造成压力

@monkeyWie 现在要求越来越严格了

现在黑 JAVA 成了潮流？ npm 和 go 用得不多，但也可以说下自己的理解。

1. maven2 是 2005 年发布的，但它现在来看还是非常领先的。
2. maven 设计了打包的各个生命周期，概念，并且非常容易写插件，生成源码，添加资源等等。
3. 用 maven/gralde 打包其它语言是相当容易的，反过来估计能做到的不多。

npm 根本和 maven 不是一个层面的对手。从两点设计就知道了：

1. 每个应用自己一个 node_modules 打包目录，无数的人搜怎么清理。（现在已经改为链接到~/下面了）
2. 小版本默认升级，`~`和`^`

npm 一个笑话就是：一个工程不说十个月，就是一星期后，就可能打包不成功了。

一个 java maven 工程，十几年过去之后，仍然可以正常打包。一个 maven plugin，十几年之后，仍然能工作。

以前还有笑话是：Java 打包出来的结果文件大。

实际上过了几年，发现 nodejs 打包结果动不动就几百 M，go 打包结果也是越来越大了。


go 的包设计非常的奇怪。

1. import 一个 git 仓库，如果这个仓库被攻击了呢？怎么保证安全性？过了好多年，才加了一个 hash 的补丁
2. go import 一个 git 仓库，是因为本身它编译时要求全是源码，不能生成中间结果
3. 作为一个用户，我要盯着一个依赖的仓库的 hash 值？依赖管理本身不应该看的是版本号么？

@xuzhzzz 我们在做 go 方面的工作，像 dapr 。

@fihserman123
@fiveelementgid
目前不招哈，年后应该会有。

可以试下 arthas profiler 和 trace:
https://arthas.gitee.io/profiler.html

https://arthas.gitee.io/trace