JavaOne 2015看到了Project Jigsaw团队关于Java 9中的模块化的一系列讨论 。它们都是非常有趣的，并且充满了宝贵的信息，我敦促每个Java开发人员都注意它们。
除此之外，我想给社区一种搜索和引用它们的方法，因此我在这里总结一下：
- 准备JDK 9
- 模块化开发简介（即将出版）
- 先进的模块化开发（即将推出）
- 拼图项目的幕后花絮（即将上映）
我努力链接到尽可能多的外部资源，以使各个帖子简短。 播放图标将带您直接进入Oracle每天为每个房间在线播放的长达十小时的视频流中的相应点。 （很棒的格式，伙计们！）（到目前为止）他们不仅弄乱了声音，而且似乎还诉诸于低音量的单声道声音，因此请确保提高音量。
让我们开始为JDK 9做准备！
总览
- 内容 ：从JDK 8迁移到JDK 9时的期望
- 演讲者 ：艾伦·贝特曼
- 链接 ： 视频和幻灯片
背景
艾伦·贝特曼（Alan Bateman）通过提供一些背景信息来开始演讲。
JDK 9和项目拼图目标
快速回顾拼图的目标。 有关更多详细信息，请参阅我关于它们的文章 。
模块化景观
简要介绍了Jigsaw项目的各种Java规范请求 （JSR）和JDK增强建议 （JEP）。
兼容性
Bateman对JDK公开的API进行了分类：
- 受支持并打算供外部使用：
- JCP标准：java。*，javax。*
- 不适用于外部使用：sun。*，rest com.sun。*，rest jdk。*
他指出，如果应用程序仅使用受支持的API并在Java N上运行，则它也应在Java N + 1上运行。 Java 9将利用此功能并更改/删除Java 8中内部或已弃用的API。
然后，他开始管理兼容性，并提到了约瑟夫·达西（Joseph Darcy）撰写的一本帖子，他建议阅读：兼容性的种类：源，二进制和行为 。 它阐明了兼容性的各个方面，并因此扩展了Java的复杂性。
JDK 9中不兼容的更改
这次演讲的大部分内容涵盖了Java 9会引起的各种不兼容性。 我的有关Java 9如何破坏您的代码的文章在很大程度上覆盖了这一点。
封装JDK内部API
Bateman首先介绍有关内部API使用的一些数据。 可以在幻灯片16上找到详细信息，但要点是，仅经常使用几个API。
不在野外使用或仅用于方便的API是非关键的。 默认情况下，这些将封装在Java 9中。那些在实际使用中很难或不可能在JDK之外创建实现的应用被视为关键。 如果存在替代方案，它们也将被封装。
在Java 9中将弃用没有替代方法的关键API，并计划在10中删除它们。JEP260为此提出了以下API：
- sun.misc.Unsafe
- sun.misc。{Signal，SignalHandler}
- 太阳杂色清洁剂
- sun.reflect.Reflection :: getCallerClass
- sun.reflect.ReflectionFactory
如果您错过了清单上的某些内容，请与拼图团队联系并为您的案件辩护（并提供数据支持）。
然后 ，他探讨了如何使用jdeps查找内部API的用法。 本部分还包含一些示例，这些示例说明了如果在JDK 9上运行有问题的代码（从此处开始）会发生什么，以及如何解决此类问题（从此处开始）。
删除API
很快 以下6种方法在Java 9中将不存在：
- java.util.logging.LogManager :: addPropertyChangeListener
- java.util.logging.LogManager :: removePropertyChangeListener
- java.util.jar.Pack200.Packer :: addPropertyChangeListener
- java.util.jar.Pack200.Packer :: removePropertyChangeListener
- java.util.jar.Pack200.Unpacker :: addPropertyChangeListener
- java.util.jar.Pack200.Unpacker :: removePropertyChangeListener
JDK / JRE二进制结构的更改
通过将JDK和JRE合并到一个通用结构中，一些现有的实践将停止工作。
Bateman描述了旧的运行时映像目录布局中的一些问题，并介绍了新的外观。 幻灯片29和30并置两种布局：
版权所有©2015，Oracle和/或其分支机构。 版权所有。
从Java 7开始，有了一个API，无论物理布局如何，工具都可以与这些文件进行交互。 这也意味着版本N可以访问版本N + 1文件。
删除的机制
如前所述 ， 认可的标准覆盖机制和扩展机制将被删除。 它们将由可升级模块取代。
其他变化
有关更改的完整列表，请参见JEP 261 （风险和假设部分）。 贝特曼列举了几个：
- 应用程序和扩展类加载器不再是java.net.URLClassLoader的实例。
- 命令行参数-Xbootclasspath和-Xbootclasspath / p被删除。
- 系统属性sun.boot.class.path已删除。
Java 9中的非拼图不兼容性
Bateman还简短地解决了两个与Project Jigsaw不相关但将在Java 9中显示并可能破坏某些代码的问题：
- 版本字符串架构会更改。 有关详细信息，请参见JEP 223-它也可以很好地比较当前和将来的版本字符串。
- 下划线不再是一个字符的标识符。
由Ricardo Villar在CC-BY-NC 2.0下发布 。
您可以为Java 9做哪些准备？
您可以执行几个准备步骤：
- 检查代码是否可以将jdeps与JDK内部API一起使用 。
- 检查可能对版本字符串架构更改敏感的代码。
- 检查代码是否使用下划线作为标识符。
- 如果您开发工具，则通常检查代码是否依赖于rt.jar ， tools.jar或运行时映像布局。
- 测试JDK 9 EA构建和Project Jigsaw EA构建。
确保将任何意外或过分有问题的发现报告给Jigsaw邮件列表 。
问题
有几个问题，我选择了两个最有趣的问题。
库如何针对Java 8和Java 9？
JEP 238将引入多版本的JAR，即可以包含特定Java版本的专用代码的JAR。
对Java 8的支持何时终止？
舞台上没有人知道确切的答案，所以他们指出了oracle.com上Oracle更新策略的文档 。 当前答案是：不早于2017年9月。
翻译自: https://www.javacodegeeks.com/2016/01/javaone-2015-prepare-jdk-9-blogcodefx.html
