1
xiaxiaocao 2018-06-01 16:26:55 +08:00 1
嵌入式这类资源有限的场景可以方便裁剪一个精简的 JDK
模块级的作用域,只有 export 的 package 才能被其他模块使用,这个是一直依赖缺少的 反射的限制,只有 open 的才能被反射调用。 可以以模块为单位做 AOT 编译 传递的依赖可以不导出,比如 B 依赖于 A,C 依赖于 B,可以让 C 看不到 A。 等等 当然现在总体上来说对开发者带来的麻烦比好处大,至少目前为止 |
2
DearMark 2018-06-01 16:33:28 +08:00
“模块化的 JVM,使之可以在内存有限的设备上运行。”
这句话,我也一知半解,安卓上好像用不到。莫非用在小型设备。 |
3
DXDE443 OP |
4
DXDE443 OP 我玩了一段时间的 java9 经常踩莫名其妙的坑,多了那个 module-info.java 要管理,如果好处只是省点磁盘空间那我还是选择屏蔽掉这个特性,能避免很多坑
|
5
xiaxiaocao 2018-06-01 16:46:04 +08:00
@DXDE443 对的。比如 iPhone。。可以去了解一下 Gluon Mobile 这个项目。手机也只是目标之一,还有车载设备,物联网啥的。能应用得多广泛就看 Oracle 的造化了。
|
6
xiaxiaocao 2018-06-01 16:47:54 +08:00
@DXDE443 不需要屏蔽,只要不加 module-info.java,还用 classpath 不用 modulepath,就基本上感觉不到它的存在。至少在第三方库都 module 化之前(这个也许需要几年时间),项目中用 module 是没什么意义的。
|
7
lurenw 2018-06-01 16:51:01 +08:00
java9 把 rt.jar 和 tools.jar 拆分之后,包依赖的确清晰了一点,不用跑个 Hello world 就要引入几百 M 的东西。
这点对嵌入式设备来说会有用,但是对平常的 se,ee,感觉并没啥卵用。 然后 module-based 的依赖结构可能是以后的趋势,python,nodejs 都这么玩。在此之前 java 的方案是 OSGI, 但是 OSGI 不是 oracle 自己的规范,要搞模块化的话,肯定得自己掌握话语权。 java9 包括 java10 感觉也只是一个过渡而已,还是得看后续官方动作。 |
9
DXDE443 OP @xiaxiaocao 有些框架可能用到一些 javax 的包,很多都是 jdk 原本自带的,java9 默认不依赖这些包的,jdk8 没这个问题,很多人把这个当 java8 用时就会发生找不到类,然后跑去 maven 下那些 jdk 本来自带的包,多一些麻烦,还是有些影响的
|
10
unlimitedsola 2018-06-03 01:28:24 +08:00
1. 减少打包体积
2. 改变应用发布方式 3. 使 jdk 自身(或者说大型项目)代码更易维护 4. 避免开发者错误使用内部( com.sun.*) API 5. 一定程度上避免 classpath 冲突(因为 a.b/a.b.c 和 x.y/a.b.c 不冲突) |