模块设计的原则:
1、防止出现编译时循环依赖(主要是编译器不支持)，但运行时是允许循环依赖的，比如GUI应用
2、明确模块的边界
几种模块设计:
API模块，聚合模块(比如java.base)
可选依赖
两种方式:
1、可选的编译时依赖(类似于maven的provided scope)声明: requires static , requires transitive static
2、使用services模式，缺点就是需要使用侵入性的ServiceLoader API
使用编译时可选依赖
module framework {
requires static fastjsonlib;
}public static void main(String... args) {
try {
Class<?> clazz = Class.forName("javamodularity.fastjsonlib.FastJson");
FastJson instance =
(FastJson) clazz.getConstructor().newInstance();
System.out.println("Using FastJson");
} catch (ReflectiveOperationException e) {
System.out.println("Oops, we need a fallback!");
}
}注意，通过requires static声明后，运行时，即使fastjsonlib模块在模块路径中，仍然会跑到异常块中，因为requies static声明的模块不会出现在模块解析路径上。除非你通过jlink打包时，加入--add-modules fastjsonlib选项来显式将其添加到模块解析路径(通过–add-modules也是作为一个root module).
使用Services模式的可选依赖
请参考之前的对于Services的探讨
Versioned Modules
jar命令打包时可以通过 –module-version=<V>选项支持将版本添加到module-info.class中作为一个属性。但是对于模块解析而言，版本是没有意义的，模块解析过程中，只看模块名，不支持版本。
所以如果需要版本化，还是得借助于Maven,Gradle之类的打包工具。
资源封装
分模块内资源访问、模块间资源访问
模块内资源访问
firstresourcemodule/
├── javamodularity
│ └── firstresourcemodule
│ ├── ResourcesInModule.java
│ ├── ResourcesOtherModule.java
│ └── resource_in_package.txt 包内资源
├── module-info.java
└── top_level_resource.txt 与module-info.java平级的资源
访问方式有几种，见下面代码:
public class ResourcesInModule {
public static void main(String... args) throws Exception {
Class clazz = ResourcesInModule.class;
InputStream cz_pkg = clazz.getResourceAsStream("resource_in_package.txt"); //<1>
URL cz_tl = clazz.getResource("/top_level_resource.txt"); //<2>
Module m = clazz.getModule(); //<3>
InputStream m_pkg = m.getResourceAsStream(
"javamodularity/firstresourcemodule/resource_in_package.txt"); //<4>
InputStream m_tl = m.getResourceAsStream("top_level_resource.txt"); //<5>
assert Stream.of(cz_pkg, cz_tl, m_pkg, m_tl)
.noneMatch(Objects::isNull);
}
}
在模块化中，不推荐使用ClassLoder::getResource*
注意上面代码中用到了Module API
跨模块资源访问
.
├── firstresourcemodule
│ ├── javamodularity
│ │ └── firstresourcemodule
│ │ ├── ResourcesInModule.java
│ │ ├── ResourcesOtherModule.java
│ │ └── resource_in_package.txt
│ ├── module-info.java
│ └── top_level_resource.txt
└── secondresourcemodule
├── META-INF
│ └── resource_in_metainf.txt
├── foo
│ └── foo.txt
├── javamodularity
│ └── secondresourcemodule
│ ├── A.java
│ └── resource_in_package2.txt
├── module-info.java
└── top_level_resource2.txt
注意，下面代码的前提是两个模块的包都没暴露给对方
public class ResourcesOtherModule {
public static void main(String... args) throws Exception {
Optional<Module> otherModule = ModuleLayer.boot().findModule("secondresourcemodule"); //<1>
otherModule.ifPresent(other -> {
try {
InputStream m_tl = other.getResourceAsStream("top_level_resource2.txt"); //<2>
InputStream m_pkg = other.getResourceAsStream(
"javamodularity/secondresourcemodule/resource_in_package2.txt"); //<3>
InputStream m_class = other.getResourceAsStream(
"javamodularity/secondresourcemodule/A.class"); //<4>
InputStream m_meta = other.getResourceAsStream("META-INF/resource_in_metainf.txt"); //<5>
InputStream cz_pkg =
Class.forName("javamodularity.secondresourcemodule.A")
.getResourceAsStream("resource_in_package2.txt"); //<6>
assert Stream.of(m_tl, m_class, m_meta)
.noneMatch(Objects::isNull);
assert Stream.of(m_pkg, cz_pkg)
.allMatch(Objects::isNull);
} catch (Exception e) {
throw new RuntimeException(e);
}
});
}
}请注意<1>中的ModuleLayer.boot() API
<2>说明了模块中的top-level资源总是可以被其他模块访问的
<3>将得到null，因为模块2的包没有开放给模块1，模块包中的资源访问遵循模块的封装原则
<4>将返回结果，上面提到资源访问遵循模块封装原则，但对于.class文件除外。(想想也是，因为是允许运行时获取到别的模块封装的Class对象，只是不允许反射调用相关方法)
<5>由于META-INF不是一个包，所以其不会遵循模块封装原则，换言之，也像top-level资源一样，是可以被其他模块访问的。
<6>Class.forName会正常调用，不过接着调用的.getResourceAsStream会返回null,就像<3>说明的一样。
记住一个原则：资源封装只针对包下的(除.class外,包下的.class文件也可以被其他模块访问)，其余的不会有封装。
那么问题来了，如果我真的很想公开包下的资源给其他模块呢？
使用open module或者opens 包名，比如:
open module aaa{
...
}
module aaa{
opens a.b.c
}
ResourceBundle
我们知道jdk有个i18n资源加载API: ResourceBundle。它的行为是扫描classpath中的所有资源，只要符合baseName和Local即可加载到。
但是java9模块化当中，无法扫描classpath,只有模块中可以使用ResourceBundle::getBundle
有两种解决方案:
1、定义一个专门的i18n资源模块，并open module
2、使用java9提供的ResourceBundleProvider接口，实现它，并将这个实现注册为服务。
Deep Reflection 与 三方框架
深度反射与浅反射的区别:浅反射只是获取基本的类信息，比如字段名，方法上的注解等，而深度反射会进行字段赋值，方法调用等。
模块化强封装带来的问题就是，我们没法使用深度反射，比如对一个exports包中的某个公开类的private域进行反射调用,field.setAccessible(true)之类的就会出现异常；对非exports包中的类进行任何深度反射都是非法的。
那么我们熟悉的ORM框架，IOC框架等都广泛地使用了深度反射。这就会导致问题。如何解决？使用Services肯定是不行的，因为框架本身改动成本就会很大，没几个愿意这么改。
有两种方式: 1、使用open module或opens 包名， opens 包名 to 模块名；2、使用Module::addOpens运行时动态open。
java9还为反射类添加了canAccess方法、trySetAccessible方法
使用open module或opens 包名
open允许对open的模块或包进行深度反射
还有个问题，假如我们想对三方提供的模块进行深度反射，那该怎么办呢，总不能去拿到别人的代码改module-info.java声明吧。这个时候就要用到java命令行参数 --add-opens <module>/<pkg>=<targetmodule>. 比如我想深度反射java.base中的java.lang包，那么可以 --add-opens java.base/java.lang=mymodule,但是如果我不使用模块化，而只是使用classpath-based，那么我们可以使用--add-opens java.base/java.lang=ALL_UNNAMED,指定想未命名ALL_UNNAMED的代码开放。
反射的替代方案:
java9基于JEP193提供了反射的替代方案用于访问非public元素MethodHandles (始于java7),VarHandles(始于java9)
示例:
src
├── application
│ ├── javamodularity
│ │ └── application
│ │ ├── Book.java
│ │ └── Main.java
│ └── module-info.java
└── ormframework
├── javamodularity
│ └── ormframework
│ └── OrmFramework.java
└── module-info.java
Book是一个POJO,里面有个private title字段
OrmFramework是一个模拟orm行为的demo，内容如下:
ublic class OrmFramework {
private Lookup lookup;
public OrmFramework(Lookup lookup) { this.lookup = lookup; }
public <T> T loadfromDatabase(String query, Class<T> clazz) {
try {
MethodHandle ctor = lookup.findConstructor(clazz, MethodType.methodType(void.class));
T entity = (T) ctor.invoke();
Lookup privateLookup = MethodHandles.privateLookupIn(clazz, lookup);
VarHandle title = privateLookup.findVarHandle(clazz, "title", String.class); // Name/type presumably found in some orm mapping config
title.set(entity, "Loaded from database!");
return entity;
} catch(Throwable e) {
throw new RuntimeException(e);
}
}Main类内容如下:
public static void main(String... args) {
Lookup lookup = MethodHandles.lookup();
OrmFramework ormFramework = new OrmFramework(lookup);
Book book = ormFramework.loadfromDatabase("/* query */", Book.class);
System.out.println(book.getTitle());
}你可能要问，为什么OrmFramework需要传入Lookup,因为只有application模块的Lookup才能有权限访问那个模块的非public元素，而OrmFramework模块自己生成的Lookup是没有权限访问的。
所以使用MethodHandles与VarHandles时需要注意Lookup的权限
利用module相关api进行反射
java.lang.module提供了三种类型的能力：1、查询模块属性(主要基于module-info.java的内容)；2、运行时动态修改模块的行为；3、模块内资源访问
类图：
1、查询模块属性(主要基于module-info.java的内容)
public class Introspection {
public static void main(String... args) {
Module module = String.class.getModule();
String name1 = module.getName(); // Name as defined in module-info.java
System.out.println("Module name: " + name1);
Set<String> packages1 = module.getPackages(); // Lists all packages in the module
System.out.println("Packages in module: " + packages1);
// The methods above are convenience methods that return
// information from the Module's ModuleDescriptor:
ModuleDescriptor descriptor = module.getDescriptor();
String name2 = descriptor.name(); // Same as module.getName();
System.out.println("Module name from descriptor: " + name2);
Set<String> packages2 = descriptor.packages(); // Same as module.getPackages();
System.out.println("Packages from descriptor: " + packages2);
// Through ModuleDescriptor, all information from module-info.java is exposed:
Set<Exports> exports = descriptor.exports(); // All exports, possibly qualified
System.out.println("Exports: " + exports);
Set<String> uses = descriptor.uses(); // All services used by this module
System.out.println("Uses: " + uses);
}
}2、运行时动态修改模块的行为
比如动态exports
Module target=...
Module current=getClass().getModule();
current.addExports("com.test.in.Hello",target);
看了这段代码，你可能要问，第二行，假如我是在别的模块中调用，那么是不是任何模块都可以修改其他模块的exports,opens等属性呢，非也，JVM运行时会判断Module对象的调用上下文,如果检测到调用时非当前模块，那么就会出现异常。这种行为叫做Caller Sensitive
Caller Sensitive
jdk定义了很多caller sensitive的方法，只要是caller sensitive的方法都会被注解@CallerSensitive标注,比如刚刚提到的Module::addExports,Field::setAccessible
Module API中可修改运行时行为的几个方法:
addExports(String pkgName, Module other)
addOpens(String pkgName, Module other)
addReads(Module other)
模块上也可以加注解
@Deprecated
module m{
}你也可以自定义模块注解
注意:@Target(value={PACKAGE, MODULE})
@Retention(RetentionPolicy.RUNTIME)
@Target(value={PACKAGE, MODULE})
public @interface CustomAnnotation {
}容器应用模式
Layers And Configurations
ModuleLayer API、boot layer、layer的父子关系、一个layer可以有多个父layer
一个layer包含了当前root模块的解析图(module resolution graph),一个应用中可以有多个layer,但是只有一个boot layer,启动时的boot layer是java给你自动创建的,你也可以手动创建layer,那么这个创建的layer的parent就是boot layer。 只有boot layer才能解析platform module,但children layer可以共享boot layer中的Platform module,但是如果boot layer中没有加载到的platform module，children module是无法使用的。
public static void main(String... args) {
Driver driver = null; // We reference java.sql.Driver to see 'java.sql' gets resolved
ModuleLayer.boot().modules().forEach(m -> System.out.println(m.getName() + ", loader: " + m.getClassLoader()));
System.out.println("System classloader: " + ClassLoader.getSystemClassLoader());
}创建ModuleLayer的示例:
ModuleFinder finder=ModuleFinder.of(Paths.get("../modules"));
ModuleLayer bootLayer=ModuleLayer.boot();
//第二个Finder参数是在第一个finder中找不到模块时才会去第二个finder中找,还有个resolveAndBind方法，区别在于，后者还会解析services provides/uses
Configuration config=bootLayer.configuration().resolve(finder,ModuleFinder.of(), Set.of("rootmodule"));
ClassLoader cl=ClassLoader.getSystemClassLoader();
ModuleLayer newLayer=bootLayer.defineModulesWithOneLoader(config,cl);上面的Configuration除了resolve方法外，还有个resolveAndBind方法，区别在于，后者还会解析services provides/uses
ClassLoaders in Layer
引入模块化以后，去掉了之前的ExtClassLoader,引入了PlatformClassLoader
如果我们为每个layer都传入不同的ClassLoader，那么则允许不同layer中存在相同的全限定类，这样可以做到隔离与相互不干扰。
Plug-in 架构
比如Eclipse,IDEA都是基于插件的应用
在Java9中，我们有两种方式来实现插件化:1、仍然利用以前的Services能力；2、结合ModuleLayer+Services实现封装性更强的插件
public class PluginHostMain {
public static void main(String... args) {
if (args.length < 1) {
System.out.println("Please provide plugin directories");
return;
}
System.out.println("Loading plugins from " + Arrays.toString(args));
Stream<ModuleLayer> pluginLayers = Stream
.of(args)
.map(dir -> createPluginLayer(dir)); //<1>
pluginLayers
.flatMap(layer -> toStream(ServiceLoader.load(layer, Plugin.class))) // <2>
.forEach(plugin -> {
System.out.println("Invoking " + plugin.getName());
plugin.doWork(); // <3>
});
}
static ModuleLayer createPluginLayer(String dir) {
ModuleFinder finder = ModuleFinder.of(Paths.get(dir));
Set<ModuleReference> pluginModuleRefs = finder.findAll();
Set<String> pluginRoots = pluginModuleRefs.stream()
.map(ref -> ref.descriptor().name())
.filter(name -> name.startsWith("plugin")) // <1>
.collect(Collectors.toSet());
ModuleLayer parent = ModuleLayer.boot();
Configuration cf = parent.configuration()
.resolve(finder, ModuleFinder.of(), pluginRoots); // <2>
ClassLoader scl = ClassLoader.getSystemClassLoader();
ModuleLayer layer = parent.defineModulesWithOneLoader(cf, scl); // <3>
return layer;
}
static <T> Stream<T> toStream(Iterable<T> iterable) {
return StreamSupport.stream(iterable.spliterator(), false);
}
}
Container架构
比如tomcat,Jetty就是基于Container的应用，支持运行时动态depoy和undeploy应用。
与Plugin-in架构的区别:1、Container支持运行时deploy和undeploy;2、Plugin-in是用的是Services思路，而Container模式不应该使用Services。这种情况下，就需要使用模块的open功能，但是我们又不应该强制应用open，那么这就需要用到ModuleLayer.Controller::addOpens了，与Module::addOpens是Caller Sensitive不同，它可以实现跨模块调用来修改模块属性。然后利用Deep reflection来实例化应用类
private static void deployApp(int appNo) {
AppDescriptor appDescr = apps[appNo];//AppDescriptor是自定义的类
System.out.println("Deploying " + appDescr);
ModuleLayer.Controller appLayerCtrl = createAppLayer(appDescr);
Module appModule = appLayerCtrl.layer()
.findModule(appDescr.rootmodule)
.orElseThrow(() -> new IllegalStateException(appDescr.rootmodule + " missing"));
appLayerCtrl.addOpens(appModule, appDescr.appClassPkg,
Launcher.class.getModule());
ContainerApplication app = instantiateApp(appModule, appDescr.appClass);
deployedApps[appNo] = app;
app.startApp();
}
private static ModuleLayer.Controller createAppLayer(AppDescriptor appDescr) {
ModuleFinder finder = ModuleFinder.of(Paths.get(appDescr.appDir));
ModuleLayer parent = ModuleLayer.boot();
Configuration cf = parent.configuration()
.resolve(finder, ModuleFinder.of(), Set.of(appDescr.rootmodule));
ClassLoader scl = ClassLoader.getSystemClassLoader();
ModuleLayer.Controller layerCtrl =
ModuleLayer.defineModulesWithOneLoader(cf, List.of(parent), scl);
return layerCtrl;
}
private static ContainerApplication instantiateApp(Module appModule, String appClassName) {
try {
ClassLoader cl = appModule.getClassLoader();
Class<?> appClass = cl.loadClass(appClassName);
if(ContainerApplication.class.isAssignableFrom(appClass)) {
return ((Class<ContainerApplication>) appClass).getConstructor().newInstance();
} else {
System.out.println("WARNING: " + appClassName + " doesn't implement ContainerApplication, cannot be started");
}
} catch (ReflectiveOperationException roe) {
System.out.println("Could not start " + appClassName);
roe.printStackTrace();
}注意点:只有jvm启动时的boot layer才能解析platform module,在这里就是Container的root layer,但children layer可以共享boot layer中的Platform module,但是如果boot layer中没有加载到的platform module，children module是无法使用的。所以Container启动时可以指定参数--add-modules ALL-SYSTEM这样便可以解析所有的platform module到layer module graph中
总之:不管是Plugin-in还是Container模式，我们都需要适应新的ModuleLayer API就像以前的ClassLoader API一样
