JinwooHwang commented on code in PR #7930: URL: https://github.com/apache/geode/pull/7930#discussion_r2395037845
########## gradle.properties: ########## @@ -64,18 +64,18 @@ geodeDockerImageName = geode:develop #JAVA_HOME to be used for compilation compileJVM= -compileJVMVer=8 +compileJVMVer=17 #JAVA_HOME to be used by tests testJVM= -testJVMVer=8 +testJVMVer=17 repeat = 100 org.gradle.caching = true org.gradle.configureondemand = false org.gradle.daemon = true -org.gradle.jvmargs = -Xmx3g +org.gradle.jvmargs = -Xmx3g --add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED Review Comment: Thank you for suggesting the inclusion of --add-exports=java.base/sun.security.x509=com.diffplug.spotless. After reviewing our current gradle.properties setup, it appears that we're not currently using that particular export. Our JVM arguments are scoped specifically to the jdk.compiler module, which Spotless relies on for its removeUnusedImports functionality—leveraging Google Java Format internally. To clarify further: Spotless itself does not make use of sun.security.x509 at all. As a code formatting tool, its core functionality doesn’t involve certificate handling or any direct interaction with JDK security internals. The export in question belongs to the java.base module and isn’t directly relevant to Spotless’s formatting operations. Moreover, the approach of using --add-exports=java.base/sun.security.x509=com.diffplug.spotless presents some fundamental incompatibilities with how Gradle plugins operate in practice. Here are a few key technical considerations: - Module System Mismatch: Gradle plugins typically run as unnamed modules within the JVM. The Spotless plugin (com.diffplug.spotless) is not a named module and is loaded dynamically via classloaders on the classpath. It doesn’t contain a module-info.class or an Automatic-Module-Name, so the JVM doesn’t recognize it as a module at runtime. - Classloader Architecture: Gradle uses a layered classloader structure, and plugin identifiers like com.diffplug.spotless are metadata—not actual module names. The JVM module system doesn’t map these identifiers to modules that can receive exports. - Dynamic Loading Context: Tools like Google Java Format (used internally by Spotless) run within the Gradle daemon’s JVM context. These classes are loaded via unnamed classloaders, which can vary across plugin and Gradle versions. As such, the only effective way to grant access to internal APIs is through ALL-UNNAMED. - Runtime vs. Compile-time Modules: Even if Spotless were to reference sun.security.x509 (which it currently does not), the export would need to target the actual runtime context—i.e., the unnamed module—not a theoretical named module that doesn’t exist in the plugin ecosystem. This is why our current configuration correctly use ALL-UNNAMED—it targets the actual execution context where Gradle plugins operate, rather than attempting to export to a non-existent module. That said, I may be missing some context or a specific use case you're addressing. If there's a scenario where this export becomes necessary, I’d be grateful for your insight. Always happy to revisit and refine the setup if there's a compelling reason -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
