ClassLoader not closed

[gnodet]

Describe the bug
During builds, a classloader created by the quarkus maven plugin is not closed completely, thus not releasing the jars after the build. This can cause problems when embedding maven. This mainly happens when using concurrent builds and a maven daemon (this always occurs the second time). This means that a reference to a zip file is not released correctly (even though the classloader created by quarkus is correctly closed).

Expected behavior
The classloader is closed.

Actual behavior

Caused by: java.util.zip.ZipException: ZipFile invalid LOC header (bad signature)
	at java.base/java.util.zip.ZipFile$ZipFileInputStream.initDataOffset(ZipFile.java:1003)
	at java.base/java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:1013)
	at java.base/java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:468)
	at java.base/java.util.zip.InflaterInputStream.read(InflaterInputStream.java:159)

[cescoffier]

Do you have more content around the stack trace?
We have a bunch of classloaders...

[gnodet]

@cescoffier I'm working on it. I may have a fix.

[gnodet]

@cescoffier The following patch seems to fix the problem:

diff --git a/core/deployment/src/main/java/io/quarkus/deployment/util/ServiceUtil.java b/core/deployment/src/main/java/io/quarkus/deployment/util/ServiceUtil.java
index d57d632b8..6ab6e3902 100644
--- a/core/deployment/src/main/java/io/quarkus/deployment/util/ServiceUtil.java
+++ b/core/deployment/src/main/java/io/quarkus/deployment/util/ServiceUtil.java
@@ -7,6 +7,7 @@ import java.io.IOException;
 import java.io.InputStream;
 import java.io.InputStreamReader;
 import java.net.URL;
+import java.net.URLConnection;
 import java.nio.charset.StandardCharsets;
 import java.nio.file.Files;
 import java.nio.file.NoSuchFileException;
@@ -39,7 +40,9 @@ public final class ServiceUtil {
 
         while (resources.hasMoreElements()) {
             final URL url = resources.nextElement();
-            try (InputStream is = url.openStream()) {
+            URLConnection con = url.openConnection();
+            con.setUseCaches(false);
+            try (InputStream is = con.getInputStream()) {
                 try (BufferedInputStream bis = new BufferedInputStream(is)) {
                     try (InputStreamReader isr = new InputStreamReader(bis, StandardCharsets.UTF_8)) {
                         try (BufferedReader br = new BufferedReader(isr)) {
@@ -47,6 +50,8 @@ public final class ServiceUtil {
                         }
                     }
                 }
+            } catch (IOException e) {
+                throw new IOException("Error reading " + url, e);
             }
         }

[gnodet]

The problem is that the ClassLoader created by quarkus is correctly closed, but using cache to access the resources holds the opened jar file in memory, so if the jar is then overwritten, it may cause problems when the resources are loaded at a later time.
I'll create a PR for that.

[geoand]

I wonder if this is also the root cause of the very large memory usage when building Quarkus itself from source.