Jigsaw Modules Support
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 2.3k
- Forks
- 959
- Avg merge
- 5d 10h
- Merged PRs (30d)
- 2
Description
At the moment, Velocity does not have any support for JPMS modules. This is expected, since it's a Java-8 compatible project loading plugins using URLClassLoader.
For plugins targeting Java 11, it is quite an improvement to take advantage of Java 11. However, PluginClassLoader loads every plugin as an unnamed module. This is the case even for jars with a manifest declaring Automatic-Module-Name, as well as plugin jars with a full module-info.java. Therefore, plugin loading makes it impossible to load own's plugin classes as anything other than an unnamed module.
The Annotation Processor
Additionally, adding a module-info.java causes the annotation processor to stop creating velocity-plugin.json. I am not entirely sure why this is. At first, I believed it due to an accidental omission of "exports testpluginpackage", but neither adding this export declaration nor adding an opens declaration solved the issue. It is still possible to manually copy a velocity-plugin.json into a jar with module-info, but as noted, no named module is created.
Velocity's Module Name
Ideally, Velocity would have an Automatic-Module-Name so that modular plugins may use a full module-info without depending on file name-based module names.
Using ModuleLayer in Plugins
Although it is possible for a plugin to create one's own ModuleLayer, and load jars, including named modules, into it, this approach is by little means useful. Without significant difficulty and access to Velocity internals, classes in the module layer will not be visible to other plugins, which prevents using modules anywhere but internally, defeating most of its advantages.
Summary
There are a few things which would need to be done for full modules support:
- Velocity declares Automatic-Module-Name. This is quite simple.
- Patch the annotation processor. As far as I can tell the processor does not like module-info, but I may be wrong on this account.
- Change plugin loading where modules are a possibility. I would imagine a multi-release JAR, with changes for plugin loading-related classes (VelocityPluginManager, PluginClassLoader, etc.) coupled with ModuleFinder/ModuleLayer, would work well.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the plugin-loading entry points named in the issue: VelocityPluginManager and PluginClassLoader, then inspect the annotation processor behavior when module-info.java is present. Map how Automatic-Module-Name, plugin metadata generation, and ModuleFinder/ModuleLayer would interact. Done means modular plugins can be loaded as named modules, metadata is generated, and Velocity declares its module name.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100