app网站公司,做广告在哪个网站做效果人流最多,微信网站 教程,同泰公司网站公司查询Java 9迫在眉睫#xff0c;它将带有完整的Project Jigsaw 。 在我从OpenJFX邮件列表的最近讨论中得知它可能会破坏现有代码之前#xff0c;我并没有对此给予太多关注。 这对于Java非常不寻常#xff0c;因此引起了我的兴趣。 我阅读了该项目的JEP和一些相关文章#xff0c… Java 9迫在眉睫它将带有完整的Project Jigsaw 。 在我从OpenJFX邮件列表的最近讨论中得知它可能会破坏现有代码之前我并没有对此给予太多关注。 这对于Java非常不寻常因此引起了我的兴趣。 我阅读了该项目的JEP和一些相关文章得出的结论是这将破坏现有代码。 是否会受到影响取决于您的项目但是您可能会受到影响并且可能会受到伤害。 总览 在粗略介绍了Jigsaw项目的内容之后我将描述可能发生的重大变化。 我从可用文档中编译了该更改列表。 当然不能保证我能抓住一切并且由于我不熟悉某些概念因此我可能会误会某些事实。 买者自负。 如果您发现错误或认为某些事情可以变得更清晰或更精确请发表评论我很乐意提供您的意见。 拼图项目 我可能会在某个时候写一个关于Jigsaw项目的更详细的描述但是现在我会很懒惰只是引用一下 该项目的主要目标是 使Java SE平台和JDK更容易地扩展到小型计算设备 总体上提高Java SE平台实现特别是JDK的安全性和可维护性 改善应用程序性能 和 使开发人员更容易为Java SE和EE平台构建和维护库和大型应用程序。 为了实现这些目标我们建议为Java SE平台设计和实现一个标准模块系统并将该系统应用于平台本身以及JDK。 该模块系统应具有足够的功能以模块化JDK和其他大型遗留代码库但仍可供所有开发人员采用。 拼图项目现场– 2015年2月11日 如果您想了解更多有关该项目的信息请查看其站点 尤其是目标和要求列表 当前版本为2014年7月起的草案3 。 这里要带走的主要东西是模块系统。 从版本9开始可以将Java代码以及JRE / JDK组织在模块中 而不是 JAR文件中。 发布时间由约尔·本·亚伯拉罕在CC-BY-ND 2.0 。 破码 这听起来像是内部重构那么为什么要破坏现有代码 好吧它并不一定要这样做兼容性甚至是项目的核心要求之一与Java一样 仅使用标准Java SE API以及可能还使用特定于JDK的API的应用程序必须以与今天相同的方式运行[…]。 拼图项目目标与要求–草稿3 重要的部分是限定条件“仅标准API”。 有很多方法可以创建应用程序这些应用程序的某些关键细节依赖于未指定或不建议使用的属性例如非标准API未记录的文件夹结构和JAR文件的内部组织。 因此让我们看看潜在的重大变化。 有关更多详细信息请确保检查项目的站点尤其是JEP 220 该站点包含对随后大部分内容的更精确描述。 内部API变得不可用 使用JAR文件任何公共类在JVM中的任何位置都是可见的。 这严重限制了JDK实现将内部API保持私有状态的能力。 取而代之的是许多方法都是可访问的并且出于各种原因而经常使用它们例如为了提高性能或解决Java运行时中的[先前]错误 Java FAQ解释了为什么这样做可能不是一个好主意 。 这随模块而改变。 每个模块都可以明确声明哪些类型作为其API的一部分可用。 JDK将使用此功能来正确封装所有内部API因此将不可用。 事实证明这可能是与Java 9不兼容的最大原因。由于它会引起编译错误因此它肯定是最不敏感的。 为了准备Java 9您可以检查代码是否依赖于内部API。 您找到的所有东西都必须以一种或另一种方式替换。 一些变通办法可能已变得不必要。 其他类可能会进入公共API。 要确定是否存在这种情况您必须进行研究甚至可能要在OpenJDK邮件列表中询问您感兴趣的功能。 内部API 那么什么是内部API 绝对是所有生活在sun.*东西。 我无法确认com.sun.*所有内容是否也都是私有的-当然有一部分是但不是全部 可能证明特别有问题的两个示例是sun.misc.Unsafe和com.sun.javafx.*所有内容。 显然前者已在许多项目中用于执行任务和性能关键代码。 根据个人经验我可以说后者是正确构建JavaFX控件的关键要素例如所有ControlsFX都依赖于这些软件包。 还需要解决许多错误。 考虑将这两种特殊情况都转换为公共API请参阅Unsafe和JavaFX 尽管有些人宁愿看到Unsafe死于火灾 。 工具支援 幸运的是您不必手动找到这些依赖项。 从Java 8开始JDK包含Java Dependency Analysis Tool jdeps 一些内部软件包的介绍 Windows和unix的官方文档它可以列出项目所依赖的所有软件包。 如果使用-jdkinternals参数运行它它将输出项目使用的所有内部API –恰好是Java 9发行之前必须处理的内部API。 JDK和JRE的合并 Project Jigsaw的主要目标是Java平台的模块化以允许灵活地创建运行时映像。 因此JDK和JRE失去了其独特的特性并成为一系列模块组合中的两个可能的点。 这意味着这两个工件将具有相同的结构。 这包括文件夹结构以及任何依赖于该结构的代码例如通过利用JDK文件夹包含子文件夹jre的事实将无法正常工作。 内部JAR变得不可用 内部JAR例如lib / rt.jar和lib / tools.jar将不再可访问。 它们的内容将以故意未指定且可能更改的格式存储在特定于实现的文件中。 假设这些文件存在的代码将停止正常工作。 由于IDE或类似工具严重依赖这些文件因此这也可能导致过渡方面的麻烦。 运行时图像内容的新URL架构 一些API在运行时将URL返回到类和资源文件例如ClassLoader.getSystemResource 。 在Java 9之前这些是jar URL 它们具有以下形式 jar:file:path-to-jar!path-to-file-in-jar Jigsaw项目将使用模块作为代码文件的容器并且不再提供各个JAR。 这需要一种新格式因此此类API会返回jrt URL jrt:/module-name/path-to-file-in-module 使用此类API返回的实例来访问文件的代码例如使用URL.getContent 将像今天一样继续工作。 但是如果它取决于jar URL的结构 例如通过手动构造它们或解析它们它将失败。 取消认可的标准替代机制 Java API的某些部分被视为独立技术并在Java社区流程例如JAXB 之外创建。 可能需要独立于JDK进行更新或使用替代实现。 认可的标准替代机制允许将这些标准的替代版本安装到JDK中。 此机制在Java 8中已弃用在Java 9中将被删除。其替代品是可升级模块 。 如果您从未听说过此消息则可能不使用它。 否则您可能想验证您使用的实现是否将成为可升级模块。 删除扩展机制 使用扩展机制自定义API可以提供给JDK上运行的所有应用程序使用而不必在类路径上命名它们。 此机制在Java 8中已弃用在Java 9中将被删除。一些有用的功能将保留。 如果您从未听说过此消息则可能不使用它。 否则您可能需要检查JEP 220以获得详细信息。 Java 9的准备 这些变化共同给任何大型项目过渡到Java 9带来了风险。评估和减少它的一种方法可能是“更新高峰”使用jdeps识别对内部API的依赖性。 修复这些问题之后请花一些时间来使用Java 9早期访问版本之一来构建和运行项目。 彻底测试系统的相关部分以了解可能出现的问题。 通过这种方式收集的信息可以返回到项目例如通过将其发布在Jigsaw-Dev邮件列表中 。 引用JEP 220的几乎最后的话 不可能确定摘要中这些更改的全部影响。 因此我们必须依靠广泛的内部测试尤其是外部测试。 […]如果其中某些更改被证明对开发人员部署人员或最终用户而言是无法克服的障碍那么我们将研究减轻其影响的方法。 反射与监视 我们已经看到Project Jigsaw将模块化Java运行时。 内部API软件包sun.*以及com.sun.* 将不可用并且JRE / JDK的内部结构将发生变化包括文件夹和JAR。 在Java 8中弃用它们之后认可的标准覆盖机制和扩展机制将在Java 9中删除。 如果您想帮助您的朋友和追随者为Java 9做准备请确保分享这篇文章。 到目前为止我们专注于Jigsaw项目的问题方面。 但这不应偏离计划中的令人振奋的而且我认为非常积极的性质。 阅读文档后我对即将发布的Java版本的范围和潜力印象深刻。 尽管对于单个开发人员而言它可能不像Java 8那样具有突破性但对于参与构建和部署的每个人尤其是大型整体项目而言甚至更是如此。 因此我一定会再次撰写有关拼图计划的文章-然后着重介绍好的方面。 如果您想了解更多信息请继续关注。 翻译自: https://www.javacodegeeks.com/2015/04/how-java-9-and-project-jigsaw-may-break-your-code.html
