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!

[KealanTolandChronicle]

This StringBuilder is captured in the DiagnosticListener lambda below, but if javac calls report() on multiple threads, then StringBuilder.append() will not be thread safe. Might be better to use StringBuffer or else explicit synchronisation, unless we can guarantee this will always be single-threaded ?

[benbonavia]

The compile is done in this thread from the call() method, so I don't think there foresee any concurrency issues

[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

[benbonavia]

Please reduce the complexity as per the sonar analysis