daniellansun opened a new pull request, #3284:
URL: https://github.com/apache/groovy/pull/3284
<!--
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.
-->
# PR title
GROOVY-12751: publish in-memory class output to a later compilation
# PR body
GROOVY-12711 keeps javac `CLASS_OUTPUT` in memory for one
`JavaAwareCompilationUnit`. A later unit on an ordinary loader still does not
see that output. This adds a publication for embedders that compile more than
once and want an earlier compilation's committed classes to stay visible,
without appending a URL to a shared loader.
`groovyc` and the Ant task already build a new loader per run. Ant's
`includeDestClasses` keeps earlier class files visible by putting the
destination directory on the classpath; the next run still uses a new loader,
and a class file that run does not write stays in the directory. `parseClass`
defines each parse on a new `InnerLoader` whose `getResource` and `addURL`
delegate to the long-lived outer loader, so a URL added on the inner loader
lands on the outer one. groovy-lsp reuses one loader and deletes the previous
javac directory, so overlapping names are a new snapshot rather than a merge.
None of those hosts turns `memClassOutput` on for a series of units, and this
change does not turn it on for them.
`MemClassOutputPublication` is the object the embedder keeps. The loader
passed to it is the long-lived parent: dependencies and any classpath already
installed there. `newCompilationLoader()` returns a child for one
`JavaAwareCompilationUnit`. The child's in-memory URL is appended when that
unit compiles, on the child only, after classpath entries the configuration or
`configure` have added. Parent-first search is unchanged, so a parent class or
an earlier URL still hides the in-memory bytes. The parent is not given a URL
and does not define the compiled classes. `loadClass` on a loader that has
already defined a class does not observe newer bytes; load the recompiled class
from the child that compiled it.
`publish(child)` copies classes that compilation has committed. A later
child resolves a name from its own stage, then from its own committed output,
then from what has been published. An overlapping name uses this compilation. A
name it does not produce stays published. That is parent-visible earlier
output, not a recompile of the union of sources. Publishing is explicit, so a
host whose next compile replaces the previous snapshot simply does not publish.
A failed compile discards its stage, and a compile that has not reached output
has nothing committed to publish. One child serves one compilation unit. The
same unit may compile again. A second unit on that child is rejected.
A single unit on an ordinary `GroovyClassLoader` behaves as in GROOVY-12711:
one new store and one URL per `open`, with no publication behind it. There is
no loader-identity cache. The `x-groovy-mem` handler stays unregistered, and
paths that escape the map are rejected before any published bytes are read.
Depends on #3242 (GROOVY-12711). Stacked on tip `1a509dc4a053`.
--
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]
