blackdrag commented on code in PR #3242: URL: https://github.com/apache/groovy/pull/3242#discussion_r4509475183
########## src/main/java/org/codehaus/groovy/tools/javac/MemClassOutputClasspath.java: ########## @@ -0,0 +1,152 @@ +/* + * 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.codehaus.groovy.tools.javac; + +import groovy.lang.GroovyClassLoader; + +import java.io.ByteArrayInputStream; +import java.io.FileNotFoundException; +import java.io.IOException; +import java.io.InputStream; +import java.net.MalformedURLException; +import java.net.URL; +import java.net.URLConnection; +import java.net.URLDecoder; +import java.net.URLStreamHandler; +import java.nio.charset.StandardCharsets; +import java.util.Collections; +import java.util.Map; +import java.util.Objects; +import java.util.UUID; +import java.util.WeakHashMap; +import java.util.concurrent.ConcurrentHashMap; + +/** + * Publishes in-memory class bytes through a {@link GroovyClassLoader} so + * joint compilation can resolve them without a class-output directory. + * <p> + * The protocol is not registered with the JVM. Only URLs created here can + * be opened, and each URL serves just the map it was given. Paths that + * escape that map are rejected. No filesystem or network access is performed. + */ +final class MemClassOutputClasspath { + + private static final String PROTOCOL = "x-groovy-mem"; + + private static final Map<GroovyClassLoader, Map<String, byte[]>> INSTALLED = + Collections.synchronizedMap(new WeakHashMap<>()); + + private MemClassOutputClasspath() { + } + + /** + * Attaches an in-memory classpath to {@code loader}, or returns the map + * already attached to that loader. A second compile on the same loader + * therefore replaces entries in place and stays visible to + * {@code getResource}. + * + * @param loader the compilation unit's class loader + * @return the mutable resource map, keyed by {@code com/example/Type.class} + */ + @SuppressWarnings("deprecation") // custom handler; URL.of(URI, handler) is not on the Java 17 baseline + static Map<String, byte[]> install(final GroovyClassLoader loader) { Review Comment: a new compilation unit per compile tends to involve a new class loader as well. There has to be a new class loader if the same class is supposed to be recompiled. Which means you are talking about a situation where we know beforehand that the second compile will not overlap with the first compile. Is that realistic? `testSecondCompileOnTheSameLoaderSeesTheNewJavaApi` does not help me here. It forces the situation, instead of going through API that would normally be used. Even if there is a long lived loader, that does not exclude short lived children for the actual compilation like GroovyClassLoader#parseClass for example does. In fact I could argue that the idea of that map is flawed in that it does not install the cache where it would actually matter. My suggestion would be to leave it out of this PR and instead make this its own issue. Then we can look at the case in isolation and with this PR already committed. And then I would also expect some of the "normal" API to be used and the structure been proven to actually exist and doing the caching. -- 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]
