java - 在类路径上使用模块化 jar 时的潜在问题

Question

在非模块化应用程序的类路径而不是模块路径上使用有效的模块化 jar(其中包含 module-info.class)时，潜在的问题是什么？目前我想到的只有两个可能的问题:

1. 由于缺乏封装而意外使用字段、方法或资源。
2. 由于 META-INF/services 中的服务提供商声明缺失或不一致导致的 ServiceLoader 问题。

还有其他我目前没有发现的潜在问题吗？

Answer 1

我认为您提到的任何事情都不会是这种情况。引用书中的一段摘录(我希望我可以这样做) The Java Module System 由我们自己的尊贵成员(member)，@Nicolai ，关于 自 java 9 以来类路径如何工作 的主题:

强调我的

Taking this backward compatibility into account, the question remains how the module system deals with types on the class path. In short, they all end up in the unnamed module, which the module system spins on the fly. This is a regular module, but it has some peculiarities, one of which is that it automatically reads all resolved modules. This is also true for modules that end up on the class path—they’ll be treated just like plain JARs, and their types will end up in the unnamed module as well, ignoring whatever their module declaration has to say. The unnamed module and modules on the class path are part of the migration story, which section 8.2 tells in full detail.

再次在 8.2.2 节

One detail that’s a little counterintuitive and easy to get wrong is what constitutes the unnamed module. It seems obvious that modular JARs become modules and hence plain JARs go into the unnamed module, right? As explained in section 8.1.3, this is wrong: the unnamed module is in charge of all JARs on the class path, modular or not. As a consequence, modular JARs aren’t bound to be loaded as modules! If a library starts delivering modular JARs, its users are by no means forced to use them as modules. Users can instead leave them on the class path, where their code is bundled into the unnamed module. As section 9.2 explains in more detail, this allows the ecosystem to modularize almost independently of one another.

最后 8.1.3 节指出:

The class path makes no distinction between plain and modular JARs: if it’s on the class path, it ends up in the unnamed module. Similarly, the module path makes little distinction between plain and modular JARs: if it’s on the module path, it ends up as its own named module. (For plain JARs, the module system creates an automatic module; for modular JARs, it creates an explicit module according to the description.)

结论

没有任何反应。如果模块化 jar 在类路径上，它将被隐式地集中到 unnamed-module 并且任何人都可以读取。此外，类路径上的任何内容都可以读取其他所有内容。此外，模块化 jar 的行为与模块系统之前的任何 jar 一样，公共(public)部分对所有人可见，而私有(private)部分仍然通过反射可见。

---

编辑2019/11/11

需要在 META-INF/services 和 module-info.java 中声明模块化 jar 中的服务类路径。书中是这样说的:

Modular JARs on the module path are the sweet spot for services in the module system, so they work without limitations. On the class path, modular JARs can cause problems, though. They’re treated like plain JARs, so they need entries in the META-INF/services folder. As a developer whose project relies on services and whose modular artifacts are supposed to work on both paths, you need to declare services in the module descriptor and META-INF/services.

...

If a modular JAR is supposed to provide services even if placed on the class path, it also needs entries in the META-INF/services directory. For each provides ${service} with ${provider} directive, create a plain file called ${service} that contains one line per ${provider} (all names must be fully qualified).

附录

除上述结论外，如果要在类路径上使用 jar，则在模块化 jar 中提供服务的库作者还需要在 META-INF/services 中声明这些服务。