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 模块的情况下工作。这比无命名和自动模块发掘的方法要好得多。

  

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
智慧校园整体解决方案是响应国家教育信息化政策,结合教育改革和技术创新的产物。该方案以物联网、大数据、人工智能和移动互联技术为基础,旨在打造一个安全、高效、互动且环保的教育环境。方案强调从数字化校园向智慧校园的转变,通过自动数据采集、智能分析和按需服务,实现校园业务的智能化管理。 方案的总体设计原则包括应用至上、分层设计和互联互通,确保系统能够满足不同用户角色的需求,并实现数据和资源的整合与共享。框架设计涵盖了校园安全、管理、教学、环境等多个方面,构建了一个全面的校园应用生态系统。这包括智慧安全系统、校园身份识别、智能排课及选课系统、智慧学习系统、精品录播教室方案等,以支持个性化学习和教学评估。 建设内容突出了智慧安全和智慧管理的重要性。智慧安全管理通过分布式录播系统和紧急预案一键启动功能,增强校园安全预警和事件响应能力。智慧管理系统则利用物联网技术,实现人员和设备的智能管理,提高校园运营效率。 智慧教学部分,方案提供了智慧学习系统和精品录播教室方案,支持专业级学习硬件和智能化网络管理,促进个性化学习和教学资源的高效利用。同时,教学质量评估中心和资源应用平台的建设,旨在提升教学评估的科学性和教育资源的共享性。 智慧环境建设则侧重于基于物联网的设备管理,通过智慧教室管理系统实现教室环境的智能控制和能效管理,打造绿色、节能的校园环境。电子班牌和校园信息发布系统的建设,将作为智慧校园的核心和入口,提供教务、一卡通、图书馆等系统的集成信息。 总体而言,智慧校园整体解决方案通过集成先进技术,不仅提升了校园的信息化水平,而且优化了教学和管理流程,为学生、教师和家长提供了更加便捷、个性化的教育体验。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值