How will JDK9 modules help for 'package-scoped

问题:

I am wondering about JDK9 modules. Say you have the following 3 packages:

com.company.product
com.company.product.impl_a
com.company.product.impl_b

Classes in package product.impl_a and product.impl_b can only be accessed by classes in package product. The user should only use classes from product package. You can imagine that passing certain flags or properties will decide whether impl_a or impl_b will be used, internally.

In JDK8-, you have to make these classes inside impl_a and impl_b public. This kinda sucks, because users can be tricked that they can use these classes. It's perfectly valid and allowed.

How can JDK9 help here? Will we declare a module for product.impl_a and another one for product.impl_b and declare that the exported classes are only to be accessed by a third module product, which will depend on the two modules product.impl_a and product.impl_b? In addition, it will be effectively impossible to declare a new module which will depend on product.impl_a or product.impl_b? Can other modules only depend on module product?

回答1:

Nothing in your question seems to indicate that these three packages need to end up in different JARs/modules. If they don't, simply put them into the same JAR, use the visibility modifiers as described, and use the following module declaration:

module com.company.product { 
    export com.company.product;
}

Then within module com.company.product you can use code from all packages as you normally would, but from outside only com.company.product is accessible.

回答2:

You can let the classes within the packages impl_a and impl_b be public and to export packages to specific modules (qualified exports) further you can use the convention as :

exports com.company.product.impl_b to third.module;

So, in your case consider these

module first.module { 
    export com.company.product.impl_a to second.module;
    export com.company.product.impl_b to third.module;
}

which means that the package com.company.product.impl_a is only exported to the second.module which now when reads first.module has access to the public types of the classes within impl_a package and similarly com.company.product.impl_b is only exported to third.module.