Need help implementing Java modules

[Alex Buckley]

On 5/9/2017 5:20 PM, Ralph Goers wrote:
> Log4j already has a robust plugin approach for users to implement
> their own Appenders, Filters, Layouts, and other Log4j components. We
> are not going to modify that as it would severely impact our users
> who have already implemented custom components and what we have works
> very well. Although the FlumeAppender I mentioned previously is
> provided by Log4j it, and all other Log4j components, are located via
> an annotation processor provided by Log4j. The processor runs at
> compile time and generates a file named
> META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat.
> All of these files are then located at runtime using
> ClassLoader.getResources(). As we parse the configuration provided by
> the user we instantiate the plugins using the class names provided in
> those files and the static builder or static factory method provided
> in the plugin class. From what I am reading in the javadoc we should
> not have any trouble with this because META-INF is not a valid
> package name so the resource file will not be hidden. Log4j uses
> reflection to call the static builder or static method to create the
> plugin.
>
> With all this in mind, if users create modules will they be required
> to declare the packages where they have created plugins as “open” to
> log4j for this to work? I am assuming that Log4j will be able to
> access this module without having to declare a dependency on it?

Basically you've got it.

- The Log4j module does not need to 'requires' any user module, nor 
invoke addReads to "read" any user module.

- Log4j code can continue to invoke Class::forName to obtain a Class 
object for a class in a user module. This is based purely on class 
loader visibility, no changes from the module system.

- Log4j code can continue to invoke Class::getMethod et al to obtain a 
Method object for a static builder/factory method. There are no access 
control rules when simply "inspecting" the Class object via getMethod, 
getMethods, getFields, etc.

- Log4j code can attempt to invoke Method::invoke on its preferred 
Method object, but for the attempt to succeed, the user module must open 
or export the class's package. If you mandate that a plugin class must 
be public with a public builder/factory method, then exporting the 
package will be enough; otherwise the package needs to be open.

- I recommend that you recommend that users should open the package to 
specifically Log4j, rather than opening the package to everyone (or 
opening the entire module). You said that your JARs will probably be 
automatic modules for some time, so you can use the 
Automatic-Module-name manifest entry to introduce a stable name that 
user modules can open to.

Alex