All 15 Class Loading & Bytecode Verification questions
More in Class Loading & Bytecode Verification
What is hot class reloading/redefinition (via Instrumentation.redefineClasses() or a JVM agent), and what are its practical limitations compared to a full class unload/reload? How would you implement a custom ClassLoader to load classes from a non-standard source, such as loading plugin JARs dynamically at runtime, and what challenges arise with class unloading? What is bytecode verification, and what specific categories of invalid or unsafe bytecode does the JVM's verifier reject before allowing a class to run? How does the same class name loaded by two different ClassLoaders create two genuinely distinct types in the JVM, and what problems does this cause (such as with singletons or ClassCastException)? How does Class Data Sharing (CDS) and Application Class Data Sharing (AppCDS) improve JVM startup time, and how does it relate to class loading and verification? How does a thread context ClassLoader (Thread.currentThread().getContextClassLoader()) solve the problem of a core JDK class needing to load an application-provided implementation class, given parent delegation normally prevents this?
Advertisement
Back to results for “Path & OS Modules”
Java › Class Loading & Bytecode Verification

How would you diagnose and resolve a 'split package' problem when using JPMS, where the same package is defined across two different modules on the module path?

Advanced

Answer

JPMS strictly forbids two modules on the module path from both containing the same package name (a "split package"), throwing a LayerInstantiationException at startup since the module system cannot unambiguously determine which module's version of that package should be authoritative -- this commonly surfaces when migrating older libraries (that weren't designed with modules in mind) to the module path, where multiple JARs might legacy-share overlapping package namespaces; resolution typically involves either keeping the offending JARs on the traditional classpath (in the unnamed module, which doesn't enforce this restriction) rather than the module path, or working with the library maintainers to properly separate the conflicting packages.
# Error at startup:
# java.lang.LayerInstantiationException: Package com.example.shared
# in both module com.lib.a and module com.lib.b

# Resolution: place conflicting JARs on the classpath instead of module path
java --class-path lib-a.jar:lib-b.jar --module-path myapp.jar --module com.example.myapp/com.example.Main
Real-world example A team migrating a legacy application to use JPMS modules discovers two third-party dependency JARs both define classes under the same internal package name, forcing them to fall back to placing those two specific JARs on the classpath (rather than the module path) until the library maintainers resolve the split package upstream.

Common follow-ups: Why does JPMS forbid split packages so strictly rather than trying to merge or pick one automatically?;What's the difference in split-package handling between the module path and the traditional classpath?

Java Platform Module System (JPMS);Build Tools: Maven & Gradle
All 15 Class Loading & Bytecode Verification questions