Add JPMS module support for JLine native access #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This implementation provides clean JPMS module support for JLine native access without modifying maven-classworlds. The changes include: 1. Updated launcher scripts (mvn, mvn.cmd) to use: - --module-path pointing to modules/ directory - --add-modules org.jline.nativ to ensure proper module loading - --enable-native-access=org.jline.nativ for targeted permissions 2. Created modules/ directory in distribution assembly: - Includes JLine JARs that need module path access - Separates them from regular lib/ dependencies 3. Updated apache-maven POM: - Replaced jline-terminal-ffm with jline-native dependency - Maintains existing native library extraction 4. Updated classworlds configuration: - Added modules/*.jar to load path for compatibility Benefits: - Moves away from --enable-native-access=ALL-UNNAMED - Uses specific module-based native access permissions - Provides clean JPMS foundation for JLine components - Maintains dual classpath/module path for compatibility Note: This branch is based on master and focuses solely on JLine JPMS changes without the broader classworlds module modifications.
Key insight from testing: Cannot use lib/ directory as module path because multiple Maven JARs export the same packages, causing JPMS resolution conflicts. Example conflict: - maven-core and maven-artifact both export org.apache.maven.artifact.resolver.filter - This violates JPMS requirement that only one module can export a package Solution: Separate modules/ directory containing only JLine JARs avoids conflicts while providing clean JPMS module resolution for native access control.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This PR implements clean JPMS module support for JLine native access, moving away from
--enable-native-access=ALL-UNNAMEDto specific module-based permissions.Key Changes
1. Updated Launcher Scripts
mvnandmvn.cmdto use:--module-pathpointing tomodules/directory--add-modules org.jline.nativto ensure proper module loading--enable-native-access=org.jline.nativfor targeted permissions2. Created Modules Directory
modules/directory in distribution assemblylib/tomodules/for proper JPMS handling:jline-native,jline-terminal-jni,jline-terminaljline-reader,jline-style,jline-builtinsjline-console,jline-console-ui,jansi-core3. Updated Dependencies
jline-terminal-ffmwithjline-nativein apache-maven POM4. Enhanced Classworlds Configuration
m2.confto load JARs from bothlib/andmodules/directoriesWhy Separate Modules Directory?
🚨 Critical JPMS Insight: Cannot use
lib/directory as module path because multiple Maven JARs export the same packages, causing module resolution conflicts.Example conflict discovered during testing:
JPMS requires that only one module can export a package. Maven's
lib/directory contains many JARs with overlapping package exports, making it unsuitable as a module path.Solution: Separate
modules/directory containing only JLine JARs avoids conflicts while providing clean JPMS module resolution.Benefits
✅ Enhanced Security: Native access limited to specific
org.jline.nativmodule instead ofALL-UNNAMED✅ Proper JPMS Support: JLine modules are properly loaded on module path without conflicts
✅ Clean Architecture: Separates JPMS modules from regular classpath dependencies
✅ Backward Compatibility: Maintains all existing Maven functionality
✅ Foundation for Future: Provides clean foundation for broader JPMS migration
Technical Details
--add-modulesto ensure JLine modules are in the resolved module graphorg.jline.nativmodule gets native access permissionsTesting
The implementation successfully:
Scope
This PR focuses solely on JLine JPMS support and does not include broader classworlds module changes. It provides a clean, isolated improvement that can be merged independently.
Related to: Issue apache#11028 - JPMS module support for
--enable-native-access