CORE-57 - Surface javac diagnostics for runtime compile failures

[sam-ross]

CORE-57 - Surface javac diagnostics for runtime compile failures

Summary

Surfaces javac diagnostics directly when runtime compilation fails, instead of masking the real compile failure as a generated-class ClassNotFoundException.

Context

CachedCompiler.compileFromJava(...) returns an empty map when javac fails. Previously, CachedCompiler.loadFromJava(...) did not distinguish that failure from a successful compile with no classes to define, and still called classLoader.loadClass(className).

With module-style classloaders, this can produce a misleading ClassNotFoundException for the generated class name, hiding the actual javac diagnostics such as missing symbols or unresolved types.

Changes

• Added an internal CompilationResult path in CachedCompiler.
• Preserved the existing map-returning compileFromJava(...) behavior.
• Captured javac diagnostics while continuing to write them to the supplied PrintWriter.
• Changed loadFromJava(...) to throw diagnostic ClassNotFoundException immediately when javac compilation fails.
• Added an explicit guard for “compilation succeeded but did not produce the requested class”.
• Returned the cached class after successful defineClass(...) instead of falling through to classLoader.loadClass(...).
• Added regression tests for:
  • successful generated-class loading with a module-like classloader
  • loader-only dependency compile failure surfacing javac diagnostics
  • successful compile output missing the requested class

Verification

mvn -q -Dtest=CachedCompilerModuleClassLoaderReproTest test
mvn -q -Dtest=CachedCompilerModuleClassLoaderReproTest,CompilerTest,CachedCompilerAdditionalTest test
mvn -q test

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[KealanTolandChronicle]

Overall looks good, just one small comment about thread safety string appending, approved!

[benbonavia]

Is it worth having the compilation result examined from within the compileFromJavaResult() method to reduce complexity in this method?

Also this way, changing of the method signature may not be required as it can still return the Map<String, byte[]> of the compiled classes if it is a success and the className exists in the map of compiled (as its provided to the compileFromJava() method. Then to allow for diagnostics to be used, you can pass in the StringBuilder on the call - this can determine whether the caller actually cares about diagnostics and add the detail if it's asked for

[sam-ross]

Good point @benbonavia, I’ve moved the compile-result checks out of loadFromJava(...) into a private compileFromJavaOrThrow(...) helper, so the caller method is simpler while keeping the existing package-private compileFromJava(...) behavior unchanged.

I did not move the throwing directly into compileFromJavaResult(...) because that method is also used to preserve the existing compileFromJava(...) contract of returning Map<String, byte[]>, including an empty map on javac failure.

I also kept CompilationResult rather than passing diagnostics in as an out-parameter. loadFromJava(...) needs the success flag as well as the diagnostics so it can distinguish “javac failed” from “javac succeeded but did not produce the requested className”. That distinction is the main CORE-57 fix, so I think keeping it explicit is clearer than inferring it from a map plus a mutable diagnostics argument.

I’ve also since split the rest of loadFromJava(...) into smaller helpers for the Sonar complexity issue: cache lookup, file-manager lookup, class definition, class-file writing, and final loaded-class lookup are now separated while preserving the existing locking behavior.

[benbonavia]

Please reduce the complexity as per the sonar analysis

[sam-ross]

Hi @benbonavia, this is ready for re-review.

I’ve refactored the method Sonar flagged at loadFromJava(...). The cache lookup, file-manager lookup, compile-result validation, class definition loop, class-file writing, and final lookup are now split into private helpers. The public method is now a short orchestration path, while preserving the existing synchronisation and duplicate-definition guard behaviour.