gnodet commented on code in PR #11029: URL: https://github.com/apache/maven/pull/11029#discussion_r3499809928
########## 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: The ClassRealm concept is not a duplication of JPMS boundaries — the two address different problems and are complementary here. ClassRealms are Maven's existing dynamic class-loading isolation mechanism (inherited from Plexus classworlds, ~20 years old). They exist because Maven loads plugins and extensions dynamically at runtime, each with its own dependency tree and potentially conflicting transitive dependencies. This is fundamentally a runtime-dynamic problem: we don't know which plugins will be loaded until we read the POM being built. JPMS resolves its module graph statically at startup, so it can't replace this. The `addExports`/`addOpens`/`addReads` methods on `ClassRealm` are specifically the **bridge** between the two worlds: since plugin classes live in realms (classpath-based, unnamed module), these methods use the `ModuleLayer.Controller` we create internally to grant access from named JPMS modules to the plugin's classloader. For example, when a plugin needs to access JLine's `org.jline.terminal.spi` package, `addExports("org.jline.terminal", "org.jline.terminal.spi")` uses the controller to open that access to the realm's unnamed module. And yes, we do create a `ModuleLayer` internally (in `Configurator.createModuleLayer()`) for jars placed on the module-path (like JLine), but it's not exposed in the API. The API only exposes the realm-level `addExports`/`addOpens`/`addReads` as a simpler abstraction for plugins to declare what module access they need — typically via `META-INF/maven/module-access` descriptors rather than direct API calls. So to answer directly: it's not a workaround for Maven not being modularized. Even if all Maven jars had `module-info.java`, we'd still need dynamic class isolation for plugins with conflicting dependencies, and we'd still need a bridge mechanism for plugins to access named modules at runtime. -- 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]
