javaone

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将两种布局并列：

从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-它也可以很好地比较当前和将来的版本字符串。
• 下划线不再允许作为一个字符的标识符。

您可以为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

javaone