根据Java 9，classloader和模块之间的关系是什么？

发布于 2025-02-01 20:40:18 字数 90 浏览 3 评论 0 原文

根据项目拼图，模块和classloader之间的关系是什么？

每个模块都有自己的唯一classloader吗？

如何在模块中获得所有课程？

原文

分享到QQ

分享到微博

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

发布评论

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

森罗 2025-02-08 20:40:18

模块由单个类加载器加载，但是类加载程序可能负责任意数量的模块。

inden noreferrer“通过一个或两个类加载程序，Bootstrap类加载程序和平台类加载程序。在启动时指定的特定于应用程序的模块，全部由系统类加载程序（也称为应用程序类加载程序）加载。这三个加载属于引导层

当您创建一个新的模块层时，您可以要求其每个模块都通过使用a << a href =“ https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/java/java/lang/modulelayer.html#definemodeleswithmanyyloaders(java.lang.module.configuration.configuration.java。 lang.classloader）“ rel =“ nofollow noreferrer”>便利方法但是，请求单个加载程序的所有模块的加载是使用函数的方法将每个模块名称映射到类加载程序，允许更多的精心设计的设置，例如启动层的设置，但是，它仍然将一个特定的模块映射到一个加载程序。因此，它仍然是一开始时所述的，一个装载机将加载一个模块，但是一个装载机可能负责多个模块。

类加载在Java中仍然是动态的，因此我们不能肯定地说，模块内有多少个类，但是属于模块的 packages 是固定的。因此，您可以轻松查询这些软件包。

Module m = Object.class.getModule(); // java.base
// using java.compiler as an example with not so many packages
m = m.getLayer().findModule("java.compiler").orElseThrow();
m.getPackages().forEach(System.out::println);

javax.lang.model
javax.lang.model.type
javax.tools
javax.lang.model.util
javax.lang.model.element
javax.annotation.processing

您可以查询模块的存储空间中的现有类文件，这可能会使您估算可能存在于模块中的类，但是如所说，类加载是动态的，因此运行时可能会有更多类，没有持久的类别贮存。

List<String> classNames;
try(var reader = m.getLayer().configuration()
                  .findModule(m.getName()).orElseThrow().reference().open()) {
    classNames = reader.list()
        .filter(s -> s.endsWith(".class"))
        .map(s -> s.substring(0, s.length() - ".class".length()).replace('/', '.'))
        .toList();
}

classNames.forEach(System.out::println);

A module is loaded by a single class loader, but a class loader may be responsible for an arbitrary number of modules.

The built-in modules are all loaded by one or two class loaders, the Bootstrap class loader and Platform class loader. The application specific modules specified at startup, are all loaded by the System class loader, also known as Application class loader. These three Built-in Class Loaders load the classes of all modules belonging to the boot layer

When you create a new module layer, you can demand that each of its modules is loaded by a distinct class loader using a convenience method but requesting the loading of all modules by a single loader is equally simple. There is a method taking a function to map each module name to a class loader, allowing more elaborated setups like that of the boot layer, however, it still has map one particular module to one loader. So it’s still as said at the beginning, one module will be loaded by one loader, but one loader may be responsible for multiple modules.

The class loading still is dynamic in Java, so we can’t say for sure, how many classes will be inside a module, but the packages belonging to a module are fixed. So you can easily query those packages.

Module m = Object.class.getModule(); // java.base
// using java.compiler as an example with not so many packages
m = m.getLayer().findModule("java.compiler").orElseThrow();
m.getPackages().forEach(System.out::println);

javax.lang.model
javax.lang.model.type
javax.tools
javax.lang.model.util
javax.lang.model.element
javax.annotation.processing

You may query the module’s storage for the existing class files, which may give you an estimate of the classes which might exist in a module, but as said, class loading is dynamic, so there might be more classes at runtime, not having a persistent storage.

List<String> classNames;
try(var reader = m.getLayer().configuration()
                  .findModule(m.getName()).orElseThrow().reference().open()) {
    classNames = reader.list()
        .filter(s -> s.endsWith(".class"))
        .map(s -> s.substring(0, s.length() - ".class".length()).replace('/', '.'))
        .toList();
}

classNames.forEach(System.out::println);

回复收藏 0 原文

~没有更多了~