Module：查看版本 v2

模塊系統於Java9引入，大幅增強了訪問權限控制。如命名模塊內的成員未聲明導出的情況下即使為public也不能在模塊外調用。JVM對於未聲明模塊的jar統一分配未命名模塊（unnamedModule），每一ClassLoader擁有其對應unnamedModule。 Module system is introduced in Java 9 which significantly increaced access control that members in a named module cannot be accessed outside the module even if it's public. For jar that doesn't declare a module JVM will assign "unnamedModule" to it. Each ClassLoader has its own unnamedModule. == How to fuck up module system's access control == We won't talk about shits like "--add-opens" here. That's not how we do ms. The easiest way to trick module system, is to replace the java.lang.Class.module field, to replace your class's module field to the module of the class you want to access. To replace the module field you need Unsafe. sun.misc.Unsafe is enough for this. Note that you should recover the module field of your class afterward otherwise that class will fail to access your other classes. Using the method we discussed above, we can construct (or get) a trusted Lookup. After that, nothing can stop us from accessing all the shits inside JVM. If you hate invoking everything using a MethodHandle, there's also a workaround: You can find native methods named addReads0,addExports0,addExportsToAll0,addExportsToAllUnnamed0 inside java.lang.Module. Invoke addExportsToAll0 and addExportsToAllUnnamed0 on every packages a module contains, then invoke addReads0 on the module your module, you can bypass the runtime module access check. However you still need to fight with the compiler's access check. [https://github.com/Rongmario/ImagineBreaker This] is a helper library aims to break out of the module system's access control. However the Github repo doesn't contain its actual source that you need to decompile the distributed jar.