廊坊网站制作策划,瑞丽住建局网站,谷德设计网站官网入口,怎么联系网站开发团队jdk 11 模块系统马克雷因霍尔德 #xff08; Mark Reinhold #xff09;的“模块系统状态 #xff08;SOMS#xff09;”已于本月初发布#xff0c;它提供了信息丰富的可读性“对Jigsaw项目中原型的Java SE平台进行了增强的非正式概述#xff0c;并被提议作为JSR 376的起… jdk 11 模块系统 马克·雷因霍尔德 Mark Reinhold 的“模块系统状态 SOMS”已于本月初发布它提供了信息丰富的可读性“对Jigsaw项目中原型的Java SE平台进行了增强的非正式概述并被提议作为JSR 376的起点。” 在本文中我总结并强调了阅读文档时发现有趣的一些概念和术语。 模块系统状态指出Java开发人员将定期使用文档中讨论的功能的子集。 这些功能和概念是“模块声明模块化JAR文件模块图模块路径和未命名模块”。 模块是“一种基本的新型Java程序组件”它是“一个自命名的代码和数据的自定义集合”。 “一个模块声明它需要哪些其他模块才能进行编译和运行。” requires关键字似乎类似于OSGI的要求捆绑或进口包装 “一个模块声明了......其打包出口 ”到其他模块。 exports关键字似乎类似于OSGI的Export-Package 。 模块声明是“ Java编程语言的新构造”提供了“模块的自我描述”。 惯例是将“模块声明的源代码”放置在“模块源文件层次结构根目录中名为module-info.java的文件中”。 “模块名称如程序包名称不得冲突。” “模块的声明不包含版本字符串也不包含对其依赖的模块的版本字符串的约束。” “ 模块化的JAR文件在所有可能的方式上都与普通的JAR文件类似除了它的根目录中还包含module-info.class文件。” “模块化的JAR文件允许库的维护者发布单个工件该工件既可以在Java 9及更高版本上作为模块使用又可以在所有版本中作为类路径上的常规JAR文件使用。” “ 基本模块定义并导出了平台的所有核心软件包”“被命名为java.base ”是“模块系统唯一已知的唯一模块”“始终存在”并由所有其他模块所依赖并且不依赖其他模块。 所有“平台模块”均以“ java. ”开头java. 前缀和“可能包括“用于数据库连接的 java.sql 用于XML处理的 java.xml和用于日志记录的 java.logging 。” 前缀“ jdk. ”应用于“ Java SE 9平台规范中未定义的模块”但“特定于JDK”的名称。 隐含可读性 关键字public可以在之后添加requires关键字状态给定的模块的模块读取可以通过读取它依赖模块读取。 换句话说如果模块B根据requires public引用了模块C提供的包则该包可由可以读取模块B的模块A读取。 通过使用关键字的在Java模块系统便于“经由服务接口和服务提供商的程序组件的松耦合” provides ... with ...以指示何时一个模块提供的服务的实现并通过使用关键字uses指示模块何时使用提供的服务。 因为给定的类与单个模块关联所以Class::getModule()将允许访问类的关联模块。 “每个类加载器都有一个唯一的未命名模块 ”从中加载与模块公开的包无关的类型。 可以使用新方法ClassLoader::getUnnamedModule检索给定的类加载器的未命名模块。 未命名的模块可以读取所有其他模块并且可以被所有其他模块读取。 “ JMOD”是“新工件格式”的“临时”名称“新工件格式”“超出JAR文件”用于保存“本机代码配置文件和其他自然不适合…放入JAR文件中的数据”。 目前这是作为JDK的一部分实现的以后可能会在Java SE中进行标准化。 上面概述的项目不包括“模块系统状态”中涵盖的“高级主题”例如合格的出口增加的可读性和层次。 原始文档也值得一读因为它具有更深入的说明简短的代码清单和说明性图形。 拼图项目和OSGi 像OSGi一样Project Jigsaw旨在在基于Java的应用程序中实现更大的模块化。 我期待看到内置的模块化支持是否可以提供与OSGi提供的某些相同的优点同时消除或减少与OSGi相关的一些缺点。 杰西卡·桑恩斯比Jessica Thornsby在Mule Drop OSGi For Beo 太复杂的文章中总结了一些开发人员对OSGi的劣势的看法这些想法导致Spring和Mule等停止使用OSGi。 Thornsby的文章引用了Dmitry Sklyut Kirk Knoerschild和Ian Skerrett的话 他们认为更好的工具更好的文档包括社区在会议上的更多了解以及通过使用的更多熟悉程度将有助于OSGi的采用并有助于克服被认为是艰难的学习曲线和复杂性。 我很好奇如果Java平台内置的模块化功能几乎可以自动带来OSGi倡导者认为可以提高OSGi的采用率的某些功能。 我怀疑通过将Jigsaw内置到平台中它会提供更好的工具支持更好地面向一般Java开发人员并且会在Java开发人员社区博客会议书籍等中得到更广泛和广泛的覆盖。 凭借这些优势我还想知道Java 9和Jigsaw是否会导致OSGi的当前用户离开OSGi或者这些用户是否会找到创造性的方式来将两者一起使用或会做自己想做的事情例如使用未命名的模块使用OSGi而不是拼图。 由于OSGi可以在Java 9之前的Java版本上使用而Jigsaw仅在Java 9和更高版本上可以使用因此在Java 9的采用逐渐升温之前不必急于将基于OSGi的应用程序迁移到Jigsaw。 Java 9中的模块化与Project JigsawPenrose和OSGi堆叠在一起可以对当前和即将到来的Java模块化方法进行有趣的讨论。 引用/相关资源 模块系统的状态 Mark Reinhold的“ Java 9模块状态”的要点 包括视频 Java模块系统初步了解 拼图快速入门 Java 9中的模块化与JigsawPenrose和OSGi堆叠 翻译自: https://www.javacodegeeks.com/2015/09/jdk-9-highlights-from-the-state-of-the-module-system.htmljdk 11 模块系统
