Java Platform Module System (JPMS), Inner Class Mechanics & SonarQube Standards

Phase 19

📂 Module 1_ Problem Solving (SonarQube-Activity.pdf) & Module 2_ JPMS

📖 Core Java Textbook Alignment: Cay S. Horstmann • Volume II — Chapter 9: The Java Platform Module System • Volume I — Chapter 6: Inner Classes

20.1 JPMS (module-info.java), Encapsulation & Inner Class Memory Leaks

📖 Cay S. Horstmann • Core Java Volume II — Chapter 9, Section 9.1 ("The Module Concept") • Volume I Ch 6

“Before Java 9, packages provided a convenient organization for classes, but package-private access did not prevent other classes on the same classpath from accessing internals. The Java Platform Module System (JPMS) solves this by grouping packages into modules defined by a module-info.java descriptor. Even a public class inside a package is strictly inaccessible to outside code unless the module explicitly exports that package.”

JPMS Directives requires vs exports vs opens: requires declares module dependencies; exports exposes public APIs for compilation; opens allows deep reflection access at runtime (crucial for Spring & JPA).
Inner Class Leak Axiom Implicit this$0 Pointer: A non-static inner class holds an implicit hidden pointer to its enclosing outer class instance. If an inner class instance outlives the outer class, it prevents the outer class from being garbage collected, causing memory leaks!

💡 Real-World Analogy: Shipping Containers with Customs Declarations

• Old Java (The Flat Classpath): Like dumping 10,000 loose products onto a shipping barge. If two jars contained the same class name, whichever loaded first won (Classpath Hell).
• Modern JPMS: Standardized shipping containers with sealed customs manifests (module-info.java). The container explicitly lists what is allowed out (exports) and what is sealed inside.

⚡ Pro-Tip / Senior Developer Rule: Always Make Inner Classes static

Default to static nested classes: public static class Node consumes zero outer-pointer memory and cannot cause outer-instance memory leaks. Only remove static if the inner class must directly mutate outer instance fields.
SonarQube Rule: Keep Cognitive Complexity $le 15$ per method; break nested loops into private helper methods or functional streams.

📂 module-info.java & StaticNestedLeakPrevention.java

// 1. JPMS Module Descriptor (module-info.java)
module com.accenture.ltt.core {
    requires java.sql;                // Depends on JDBC module
    requires org.slf4j;               // Depends on logging module
    exports com.accenture.ltt.api;    // Exposes public API package to callers
    opens com.accenture.ltt.entity to org.hibernate.orm.core; // Reflection access for JPA
}

// 2. Memory-Safe Static Nested Class vs Leaking Non-Static Inner Class
package com.accenture.ltt.clean;

public class MemorySafeCache {
    private byte[] largeOneMegabytePayload = new byte[1024 * 1024];

    // CORRECT: static nested class has ZERO hidden reference to outer instance!
    public static class CacheKey {
        private final String key;
        public CacheKey(String key) { this.key = key; }
    }

    /* ANTI-PATTERN (Memory Leak):
    public class LeakingKey {
        // Holds hidden pointer: MemorySafeCache.this
        // Outer 1MB payload CANNOT be garbage collected as long as LeakingKey is in memory!
    } */
}

👁 Execution & Memory Breakdown • Module & Memory Boundaries

Step 1 (JPMS Verification): The JVM verifies module dependency graphs at startup time. If a required module is missing, startup fails immediately with FindException before processing requests.

Step 2 (Memory Allocation): static class CacheKey allocates only the memory for its own fields (the String reference), detached from the outer class lifecycle.