Skip to content

Upgrade to JLine 4.x and Replace Broad Native Access with Targeted Module Access #11028

@gnodet

Description

@gnodet

New feature, improvement proposal

Upgrade to JLine 4.x and Replace Broad Native Access with Targeted Module Access

Summary

Maven currently uses the broad --enable-native-access=ALL-UNNAMED JVM flag to enable native access for JLine's terminal functionality. This approach grants native access to all unnamed modules, which is overly permissive from a security perspective. We should upgrade to JLine 4.x (when available) and replace this with the more targeted --enable-native-access=org.jline.terminal.ffm to follow the principle of least privilege.

Current State

JLine Version: 3.30.4
Native Access Configuration: --enable-native-access=ALL-UNNAMED
Location:

  • apache-maven/src/assembly/maven/bin/mvn (line 245)
  • apache-maven/src/assembly/maven/bin/mvn.cmd (line 259)
cmd="\"$JAVACMD\" \
  $MAVEN_OPTS \
  $MAVEN_DEBUG_OPTS \
  --enable-native-access=ALL-UNNAMED \
  -classpath \"$LAUNCHER_JAR\" \
  \"-Dclassworlds.conf=$CLASSWORLDS_CONF\" \
  \"-Dmaven.home=$MAVEN_HOME\" \
  \"-Dmaven.mainClass=$MAVEN_MAIN_CLASS\" \
  \"-Dlibrary.jline.path=${MAVEN_HOME}/lib/jline-native\" \
  \"-Dmaven.multiModuleProjectDirectory=$MAVEN_PROJECTBASEDIR\" \
  $LAUNCHER_CLASS \
  $MAVEN_ARGS"

Proposed Changes

1. Upgrade to JLine 4.x

JLine 4.x will include comprehensive JPMS (Java Platform Module System) support via PR #1374, which:

  • Adds proper module-info.java files for all JLine modules
  • Provides the org.jline.terminal.ffm module for Foreign Function & Memory API support
  • Enables targeted native access permissions
  • Maintains backward compatibility with classpath-based applications

2. Replace Broad Native Access Flag

Current: --enable-native-access=ALL-UNNAMED
Proposed: --enable-native-access=org.jline.terminal.ffm

This change:

  • ✅ Follows the principle of least privilege
  • ✅ Reduces security attack surface
  • ✅ Provides the same functionality with better encapsulation
  • ✅ Aligns with Java platform security best practices

3. Module Path Migration

Moving JLine to the module path (instead of classpath) will require updates to plexus-classworlds to support:

  • Module path configuration in m2.conf
  • Mixed classpath/module path scenarios
  • Proper module resolution and loading
[plexus.core]
load       ${maven.conf}/logging
optionally ${maven.home}/lib/ext/redisson/*.jar
optionally ${maven.home}/lib/ext/hazelcast/*.jar
optionally ${user.home}/.m2/ext/*.jar
optionally ${maven.home}/lib/ext/*.jar
load       ${maven.home}/lib/maven-*.jar
load       ${maven.home}/lib/*.jar

Benefits

  1. Enhanced Security: Targeted native access reduces the attack surface
  2. Better Encapsulation: JPMS provides strong module boundaries
  3. Future-Ready: Prepared for modern Java features (Project Loom, Panama)
  4. Performance: Module system enables JVM optimizations
  5. Maintainability: Clear module dependencies prevent classpath issues

Implementation Plan

  1. Phase 1: Wait for JLine 4.0 release with JPMS support
  2. Phase 2: Upgrade Maven's JLine dependency to 4.x
  3. Phase 3: Update plexus-classworlds to support module path
  4. Phase 4: Modify Maven launcher scripts to use targeted native access
  5. Phase 5: Update m2.conf to place JLine modules on module path

Compatibility

  • Backward Compatible: Existing Maven installations continue to work
  • Java Version: Requires Java 9+ for module system (already required by Maven 4.x)
  • Plugin Compatibility: No impact on Maven plugins or user projects

Related Work

Acceptance Criteria

  • JLine 4.x dependency integrated
  • --enable-native-access=org.jline.terminal.ffm replaces ALL-UNNAMED
  • JLine modules moved to module path
  • plexus-classworlds supports module path configuration
  • All Maven functionality works (terminal input, colors, progress, etc.)
  • Integration tests pass
  • Documentation updated

Priority: Medium
Effort: Large (requires coordination with JLine 4.x release and plexus-classworlds updates)
Security Impact: Positive (reduces native access scope)

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions