@qwingmix 我买的雷凌双擎。。

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~

emmm 竟然是 java 版块。。springMVC 天然支持 restful 为啥他们不会用……

我猜后台是 php

大多数接口不好用的话都会在新版本中重新实现，比如 URL，不好改的就像楼上说的那样，新写了一套接口。
不好用也不常用还过时的东西，基本上就准备扔掉了，比如 9 之后模块化借机拆出来许即将扔掉的模块，比如 CORBA，nashorn

IDEA EAP 版本不要钱

@billlee 我是和 kotlin 混用的时候去掉的 lombok

用 long 就可以了。哈哈哈哈哈哈

@zhenjiachen 我也发现了，觉得还是 java 更流畅一些

尴尬，贴错了图片地址了

@qiyuey

这截图里面的 idea 已经运行了两个小时了，只有 108 GC 用时 3.560s。可能也跟我现在使用程度轻有关，我只是在两个项目之前切换，写的 5 个模块的 kotlin 项目

@l8g
-Xms1400m
-Xmx1400m

其它的都是自带的原参数了。
我也觉得应该没啥优势，但是从 jvisualvm 里面的记录来看，GC 次数少多了。。

@jhsunnyshine 兄弟，这显示器用得咋样？

目测会引来一堆 phper 喷你，一部分也会喷 java 然后劝你转 golang

我用五笔，但是不是大佬

仓库有类型的，有 proxy/hosted/group
public 那个就是一个组，里面可以配置多个 proxy 或 hosted.
你建一个 hosted 用于上传私有 jar 包，都加进 public 里面就可以统一通过 public 来访问了。


结贴，散花

自从新版 IDEA 对 maven 的支持变差以后觉得这两个好像用哪个都一样了。

HBase 是一个非常成熟且稳定的东西了，不过 HBase 做查询不是强项吧？
TiDB 只听过没用过。