拆分包：Java模块与密封的罐子

发布于 2025-01-27 17:39:54 字数 80 浏览 2 评论 0 原文

密封包装/罐子和Java模块系统都禁止在几罐罐子上划分包装。这是否意味着模块中包含的所有软件包都是隐式密封的？如果不是，明确密封罐子会更换什么？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夏至、离别 2025-02-03 17:39:54

是的，模块中的软件包始终被隐式密封。这是在 class ：

a 软件包自动定义了为命名模块中的类定义的属性：

软件包的名称是从二进制名称类别。由于指定模块中的类必须在命名的软件包中，因此派生的名称永远不会为空。

包装用模块位置作为代码源，如果已知。

未指定的规范和实现标题，版本和供应商。

包装上的任何注释将从上面指定的 potpage> infage-info.class 读取。

我还进行了快速测试，以验证模块包上的 issealed（）确实返回 true 。但是，必须注意的是，（命名）模块和软件包之间的关系具有基本的性质，因此与 issealed（）返回 true 的事实无关。后者只是旧API与此新功能互动的自然方式。

一个未命名模块的密封包仅影响特定类加载程序的运行时软件包，因为每个类加载程序都可以具有相同名称的软件包，这被视为不同的运行时软件包。

相比之下，指定模块的每个软件包必须明确属于整个模块层中的一个模块，并且模块层可以跨越多个类加载程序，例如跨越引导加载程序，平台加载程序和应用程序加载程序。

这会影响类加载过程。旧的加载方式仍然用于未命名的模块，特征类加载程序委托，每个加载程序首先查询其父母加载程序。当父加载程序失败时，类路径条目是线性查询的，直到找到类。

初始化模块层时，所有的软件包名称及其所有模块都会记录下来，因此，当尝试加载类的尝试时，可以从合格名称中派生包名称并甚至在加载班级之前映射到模块因此，只有该模块的已知来源需要查询。

Yes, packages within modules are always implicitly sealed. This is specified in the documentation of the Package class:

A Package automatically defined for classes in a named module has the following properties:

The name of the package is derived from the binary names of the classes. Since classes in a named module must be in a named package, the derived name is never empty.

The package is sealed with the module location as the code source, if known.

The specification and implementation titles, versions, and vendors are unspecified.

Any annotations on the package are read from package-info.class as specified above.

I also made a quick test to verify that isSealed() on a module’s package did indeed return true. However, it must be noted that the relationship between (named) modules and packages is of a fundamental nature and hence, independent of the fact that isSealed() returns true. The latter is just the natural way for the old API to interact with this new feature.

A sealed package of an unnamed module only affects the runtime package of the particular class loader, as each class loader can have a package of the same name, which is considered a different runtime package.

In contrast, each package of a named module must unambiguously belong to a single module within the entire module layer and a module layer can span multiple class loaders, e.g. the boot layer spans the bootstrap loader, the platform loader, and the application loader.

This affects the class loading process. The old way of loading, which is still used for the unnamed module, features class loader delegation where each loader queries its parent loader first. When the parent loader failed, the class path entries are queried linearly for the class until a class is found.

When a module layer is initialized, all package names and their owning modules are recorded, so when an attempt to load a class is made, the package name can be derived from the qualified name and mapped to a module even before the class is loaded and therefore, only the module’s known source needs to be queried.

回复收藏 0 原文

~没有更多了~