szq8014

其实 2019.2 的时候就带了，默默默的带了但是没有任何声明，试了一下还行，然后默默的换回了我的逮虾户

感觉可以看看 lombok enhance 一下

是同一个异常，都是 NumberFormatException ，只不过后面那个又给包装了一层，直接换成 error 扔出来了，毕竟是 static 的发生在类加载期，初始化失败当然不能继续运行了，抛个 Error 是可期的

感觉 FF 字体渲染得好

你再了解一下 graalvm 和 AOT 岂不是能跳起来~

1608536 元， 哦，忘了看小数点

@lihongjie0209 +1 目前依赖冲突就是通过选一个特定版本就解决了，觉得最麻烦的冲突也就是日志库的冲突了，有些库没有用 slf4j，直接依赖了 log4j 或 commons-logging，而项目用的 log4j2/logback，而解决方式就是用现有的 log4j 接口的实现再转回 slf4j 里面。log4j-to-slf4j, log4j-slf4j-impl 能让人迷糊，别的真没这么费脑子

感觉很多人都理解错了， 依赖 [存储] 和 [加载] 是两回事。。

嵌套存储：
app
-- m1-v1
-- -- m3-v1
-- m2-v1
-- -- m1-v2
-- -- -- m3-v2
扁平存储
app
-- m1-v1
-- m1-v2
-- m2-v1
-- m3-v1
-- m3-v2

扁平存储显然是并不存在什么多版本共存的问题，而且比嵌套存储更节省那一点点存储空间的，也并不限制你打包只能加载一个模块的一个版本，有能力当然可以把 commons-lang3 的所有版本全打进 fat-jar 或 war 包里，只不过 java 的默认类加载制度的限制导致 maven 只能默认选一个它约定下的最合适的一个版本，这并不是扁平化的存储导致的。


想想如果 java 需要支持多版本 jar 包存在该如何改呢？
1. 改语法 import, 在包里面加上版本？ 需要源码改动不太现实~
2. 把依赖关系带到运行时告诉类加载器，有一个类似 maven 的 pom.xml 的东西，告诉这个类依赖的版本。比如打包时直接把所有的 jar 重新打，在 META-INF 里面加上依赖描述。
3. 学 nodejs 弄目录嵌套

在 java 里面多版本共存还有许多问题，比如两个版本的同一个类在 jvm 看来是两个完全没关系的东西，假如一个接口返回这个类实例传再传给另一个接口时，虽然参数是需要这个类，传的也是，但是仅仅是因为不是同一个类加载器加载的，会报 class cast exception 的。

这是 java 的问题，不是扁平化包管理的问题。

所以大家别吐槽 maven 了，锅不在 maven~