Debugging Maven Multi‑module Deployment Issues Caused by JDK Constant Compilation Optimization

Background : In a Maven multi‑module project, after modifying a static constant used for Redis key prefixes, the application still behaved as if the old value were present, leading to keys have different slots errors in a Redis‑cluster environment.

Project Structure : The project consists of two modules, build-api (version 1.0.0‑RELEASE) and build-center, where build-center depends on build-api. The original constant is defined in build-api:

/**
 * 用来定义Redis key的前缀
 */
public class ConfigConstant {
    public static final String METADATA_CONFIG_PATH = "METADATA_CONFIG_PATH:";
}

The build-center module references this constant in ConfigRedisConstant to build full Redis keys:

/**
 * 根据参数组装redis的完整key
 */
public class ConfigRedisConstant {
    public static String createMetadataRedisName(String key) {
        StringBuilder cacheKey = new StringBuilder(ConfigConstant.METADATA_CONFIG_PATH);
        cacheKey.append(key);
        return cacheKey.toString();
    }
}

Refactor Attempt : To fix the slot issue, the constant was changed to include curly braces so that the key is hashed to the same slot:

public class ConfigConstant {
    public static final String METADATA_CONFIG_PATH = "{METADATA_CONFIG_PATH:}";
}

However, the build-api module version was not updated, so the old JAR (without braces) was still used during compilation of build-center. After packaging and deployment, the runtime still used the old constant value, causing the error.

Investigation Steps :

Verified that the compiled JAR contained the old constant value.

Remote debugging showed the constant value as expected, but the resulting cacheKey lost the braces.

Used Arthas to inspect class loaders; both classes were loaded by the same LaunchedURLClassLoader, ruling out class‑loader isolation.

Decompiled the ConfigRedisConstant class with Arthas ( jad) and discovered that the compiled bytecode had inlined the old constant value due to Java’s compile‑time constant folding.

Root Cause : The static final constant was compiled into the dependent module ( build-center) as a literal. Because the build-api JAR version was not bumped, Maven used the old JAR during compilation, embedding the stale value. The newer source with braces was never compiled into build-center, leading to the “ghost” debugging phenomenon.

Recommendations :

Whenever a public static constant in an API module is changed, increment the API module’s version and update dependent modules to use the new version.

Adopt the practice of treating API modules as immutable contracts; any change requires a new release.

Consider avoiding compile‑time constant inlining for values that may change, e.g., by using a method or configuration file instead of a public static final literal.