Pav*_*l_K 6 java java-9 java-module unnamed-module
我试图了解JPMS的工作原理.
从这里开始
类路径还没有完全消失.所有JAR(模块化或非模块化)和类路径上的类都将包含在未命名模块中.与自动模块类似,它导出所有包并读取所有其他模块.但显然它没有名字.因此,命名的应用程序模块不能要求和读取它.未命名的模块又可以访问所有其他模块.
请注意...on the classpath will be contained in the Unnamed Module.模块是单数.
从这里开始
为了兼容性,类路径上的所有代码都打包为一个特殊的未命名模块,没有隐藏的包和对整个JDK的完全访问权限.
再次unnamed module.模块是单数.
我是否理解JPMS中始终只有一个未命名的模块？是否意味着在Java9之前开发但未针对Java9更新的应用程序将作为一个未命名的模块加载？
我是否理解 JPMS 中始终只有一个未命名的模块？
是的，有一个未命名的模块。未命名模块与未命名包的现有概念非常相似。
在使用分层文件系统存储包的 Java SE 平台的实现中，一种典型的策略是将未命名的包与每个目录相关联；一次只能观察到一个未命名的包，即与“当前工作目录”相关联的包。“当前工作目录”的确切含义取决于主机系统。
这是否意味着在 Java9 之前开发且未针对 Java9 更新的应用程序将作为一个未命名的模块加载？
是的，对于放置在类路径上的那些 jars 将被视为单个未命名的模块。带有未命名模块概念的自下而上迁移用一个类似的例子说明了这一点：
例如，假设上面显示的应用程序最初是为 Java SE 8 构建的，作为放置在类路径上的一组名称相似的 JAR 文件。如果我们在 Java SE 9 上按原样运行它，那么 JAR 文件中的类型将在未命名模块中定义。
这里可能出现的实际问题 是未命名模块与哪个类加载器相关联？ 关于未命名模块的模块系统状态对此进行了澄清。
事实证明，每个类加载器都有自己独特的未命名模块，由新
ClassLoader::getUnnamedModule方法返回。 如果类加载器加载了一个未在命名模块中定义的类型，那么该类型被认为在该加载器的未命名模块中，即，该类型对象的方法将返回其加载器的未命名模块。通俗地称为“未命名模块”的模块就是应用程序类加载器的未命名模块，当它们位于未由任何已知模块定义的包中时，它从类路径加载类型。getModuleClass
在ClassLoaderJava中，9个州修订如下：
Java 运行时具有以下内置类加载器：
Bootstrap class loader: 虚拟机的内置类加载器...
Platform class loader: ... 允许升级/覆盖定义到平台类加载器的模块，并且升级模块读取定义到平台类加载器及其祖先以外的类加载器的模块，然后平台类加载器可能必须委托给其他类加载器，例如应用程序类加载器。换句话说，为平台类加载器及其祖先以外的类加载器定义的命名模块中的类可能对平台类加载器可见。
System class loader:也称为应用类加载器，区别于平台类加载器。系统类加载器通常用于在应用程序类路径、模块路径和 JDK 特定工具上定义类。平台类加载器是系统类加载器的父级或祖先，所有平台类对它都是可见的。
我是否理解JPMS中始终只有一个未命名的模块？
简而言之
一般来说,没有.但是让我们这样说:如果你在类路径上放置一些甚至所有JAR,并且你的应用程序没有创建类加载器来加载任何其他内容,那么你只需要关注一个未命名的模块.
更详细
每个ClassLoader都有自己的未命名模块,用于表示从类路径加载的类.这是必要的,因为模块系统要求所有内容都在模块中.
正如nullpointer的答案详细解释的那样,默认情况下,应用程序将使用三个单独的类加载器.它可能会启动自己的类加载器,例如加载插件.但是,如果它不这样做,所有应用程序代码将最终在系统/应用程序类加载器中,因此在同一个未命名的模块中.这就是为什么通常只有一个你需要关心的原因.
是否意味着在Java9之前开发但未针对Java9更新的应用程序将作为一个未命名的模块加载？
这与代码(应用程序,框架,库)是否以Java 9为目标无关 - 它只取决于您在类路径或模块路径上放置JAR的路径.
如果它在类路径上,它将与其他类路径内容一起在未命名的模块中结束.对于没有模块描述符的普通JAR,也适用于包含一个JAR的模块化JAR.
如果它在模块路径上,它将获得自己的模块.如果它是模块化JAR,它将获得一个显式模块,如模块系统状态中描述的那样- 普通JAR变为自动模块(注意复数:每个JAR一个自动模块).
| 归档时间： |
|
| 查看次数： |
2342 次 |
| 最近记录： |