RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code Programs [v4]

Archie Cobbs acobbs at openjdk.org
Fri Oct 27 14:29:33 UTC 2023

On Fri, 27 Oct 2023 11:01:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 238:
>>> 236:         var memoryConfig = parentLayer.configuration().resolveAndBind(memoryFinder, ModuleFinder.of(), Set.of(applicationModule.name()));
>>> 237:         var memoryClassLoader = new MemoryClassLoader(inMemoryClasses, parentLoader, applicationModule, descriptor, this::compileJavaFileByName);
>>> 238:         var memoryController = ModuleLayer.defineModules(memoryConfig, List.of(parentLayer), __ -> memoryClassLoader);
>> It would be helpful if the comment were expanded to explain why memoryClassLoader is needed here. ClassLoaders created by the defineModulesXXX methods are capable to loading modules in memory file systems, the issue is the dynamic compilation (I think).
> I'll add a comment explaining that the `MemoryClassLoader` is required here to compile referenced types from their source files on-the-fly.

Random comment here, feel free to ignore...

There appear to be two similar implementations of a "Memory" ClassLoader in the JDK... the one under discussion here, and `jdk.jshell.execution.DefaultLoaderDelegate.RemoteClassLoader`. Perhaps someday they could be consolidated.


PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1374662423

More information about the compiler-dev mailing list