Reflection vs Encapsulation – Stand Off in the Java Module System(5)

  看起来又要凑一个数了。然而我又翻了一篇，就这么写博客能写到我退休。

  

  Class Path Trickery

  类路径技巧

  Now we’re entering less modular ground. As you might know java and javac require modules to be on the module path, which is like the class path but for modules. But the class path is not going away and neither are JARs. There are two tricks we can employ if we have access to the launching command line and can push the artifact around (so this won’t work for JDK modules).

  现在我们进入较少的模块化区域。或许你知道java和javac需要模块在模块路径上，模块路径就像类路径(class path)之于类。但类路径不会消失，JAR包也不会。如果我们可以访问启动命令行并且可以推送生成包（这对JDK模块不起作用），我们可以使用两个技巧。

  Unnamed Module

  匿名模块

  First, we can drop the owning module onto the class path.

  首先， 我们可以把包含的模块放到类路径(classpath)上.

  How does the module system react to that? Since everything needs to be a module the module system simply creates one, the unnamed module, and puts everything in it that it finds on the class path. Inside the unnamed module everything is much like it is today and JAR hell continues to exist. Because the unnamed module is synthetic, the JPMS has no idea what it might export so it simply exports everything – at compile and at run time.

  模块系统将对此如何反应？因为所有的东西都需要模块，所以模块系统就会简单的创建一个，被称为未命名的模块，并把所有东西放在里面，使它能在类路径上被发现。在无名的模块内部，一切都像现在一样，JAR冲突会继续存在。因为未命名的模块是合成的，JPMS不知道它会导出什么东西来，所以它就简单的导出所有的东西，包括编译和运行时。

  If any JAR on the class path should accidentally contain a module descriptor, this mechanism will simply ignore it. Hence, the owning module gets demoted to a regular JAR and its code ends up in a module that exports everything:

  如果类路径上的任何JAR不小心包含了一个模块描述符，则该机制将忽略它。因此，拥有它的模块将会被降级，普通JAR及其编码会在一个能导出一切东西的模块里结束：

public: ✓   protected: ✓   default: ✓   private: ✓

  Ta-da! And without touching the owning module, so we can do this to modules we have no control over. Small caveat: We can not require the unnamed module so there is no good way to compile against the code in the owning module from other modules. Well, maybe the caveat is not so small after all…

  RUA! 我们对没有访问权限的模块使用这种方式，并且不用接触到包含的模块。小小的警告: 我们不能依赖匿名模块，所以并没有什么好方法能够在其他模块中，针对包含的模块进行编译。好吧，这也许并不是一个小小的警告。。

  

  Automatic Module

  自动模块

  The second approach is to strip the owning module of its descriptor and still put it on the module path. For each regular JAR on the module path the JPMS creates a new module, names it automatically based on the file name, and exports all its contents. Since all is exported, we get the same result as with the unnamed module:

  第二种方式是在描述中去掉包含的模块，但是依然把他们放到模块路径上。对模块路径上的每个常规JAR，JPMS都会根据文件名自动创建一个模块，并且会导出(exports)所有内容。因为所有的东西都导出了，我们得到了和匿名模块一样的结果:

  

public: ✓   protected: ✓   default: ✓   private: ✓

  Nice. The central advantage of automatic modules over the unnamed module is that modules can require it, so the rest of the application can still depend on and compile against it, while the intruder can use reflection to access its internals.

  Nice。相比匿名模块自动模块最大的好处是其他模块可以对它写依赖声明(require)，所以应用中的其他部分依然可以针对它进行依赖和编译，同时，入侵(intruder)模块也可以通过反射获得访问内部代码的权限。

  One downside is that the module’s internals become available at run time to every other module in the system. Unfortunately, the same is true at compile time unless we manage to compile against the proper owning module and then rip out its descriptor on the way to the launch pad. This is iffy, tricky, and error-prone.

  这种方式有一个缺点，就是在运行时，该模块内部的东西会向系统中的其他所有模块开放。不幸的是，编译时也是如此，除非在编写完成之后我们适当的对包含的包进行管理，之后删掉其中的依赖描述。 这样会变得复杂而且容易出错，并且这种方式看起来也没啥前途。

  Command Line Escape Hatches

  

   Since we’re fiddling with the command line anyway, there is a cleaner approach (maybe I should’ve told you about it earlier): Both javac and java come with a new flag --add-opens, which opens additional packages.

  不管我们用什么方式摆弄命令行，最简单的方法（或许我应该在之前告诉你）包括 javac 和 java 命令行都支持一个新的参数 --add-opens 用来打开额外的包。

java \
    --module-path mods \
    --add-modules owner \
    --add-opens owner/owner=intruder \
    --module intruder

  This works without changing the owning module and applies to JDK modules as well. So yeah, much better than the unnamed and automatic module hacks.

  这个可以让你在不修改 JDK 模块的情况下工作。这比无命名和自动模块发掘的方法要好得多。

  

   文章最后面不是我翻的，不知道翻译的人从事啥工作，总感觉他们喜欢在英语翻译职业的角度来搞事情。