gnodet commented on code in PR #11029: URL: https://github.com/apache/maven/pull/11029#discussion_r3502303832
########## api/maven-api-classworlds/src/main/java/org/apache/maven/api/classworlds/ClassRealm.java: ########## @@ -0,0 +1,223 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.api.classworlds; + +import java.io.Closeable; +import java.net.URL; + +import org.apache.maven.api.annotations.Experimental; +import org.apache.maven.api.annotations.Nonnull; +import org.apache.maven.api.annotations.Nullable; + +/** + * A class loading realm that provides isolated class loading with controlled imports and exports. + * <p> + * A ClassRealm represents an isolated class loading environment with its own classpath Review Comment: Yes! This is precisely the approach we just implemented for modular plugins in this PR — see \`DefaultClassRealmManager.createModularPluginRealm()\`. The code is almost identical to your sketch: ```java ModuleFinder finder = ModuleFinder.of(modulePaths.toArray(new Path[0])); Set<String> moduleNames = finder.findAll().stream() .map(ref -> ref.descriptor().name()) .collect(Collectors.toSet()); ModuleLayer parentLayer = implWorld.getModuleLayer() != null ? implWorld.getModuleLayer() : ModuleLayer.boot(); Configuration cfg = parentLayer.configuration().resolveAndBind(ModuleFinder.of(), finder, moduleNames); ModuleLayer.Controller controller = ModuleLayer.defineModulesWithOneLoader(cfg, List.of(parentLayer), parent); ``` A few design decisions worth noting: - **Opt-in via plugin descriptor**: Plugin authors declare `<modular>true</modular>` in their `plugin.xml`. This is a hard contract — if the module graph can't be resolved (split packages, missing `module-info.class`, etc.), the build fails with `ModuleLayerCreationException`. No fallback to classpath loading. - **Flat layer hierarchy**: All plugin layers are siblings under the same parent layer (the runtime layer from `ClassWorld` if available, or the boot layer). No nesting. - **DI instead of ServiceLoader**: Rather than `ServiceLoader.load(layer, MyService.class)`, we use Maven's `maven-di` `Injector.discover()` with the layer's classloader. This integrates modular plugins into Maven's existing injection infrastructure. No Plexus/Sisu for modular plugins. - **Per-realm storage**: The `ModuleLayer` and `Controller` are stored on the `ClassRealm`, not on `ClassWorld` — each plugin gets its own isolated layer/loader, and the layer's classloader is closed when the realm is disposed. So yes, dynamic module layers work well for this. Thanks for the suggestion — it validated the direction we were already heading. -- 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]
