I looked at the bugs filed from LLM, and although I can’t judge several of them since I don’t know anything about maven code, I can say with confidence that I wish this tool had been available when I was actually working on software. I spent enormous amounts of time finding problems like these and fixing them. This would have made my life much pleasanter.
I don’t see where anyone said the list Elliotte posted in this thread is mostly spam. It looks to me that Guillaume said 3 out of 15 were invalid. I’ll shut up now. David Jencks Sent from my iPhone > On Jul 1, 2026, at 1:12 PM, Tamás Cservenák <[email protected]> wrote: > > I'm sorry David, but you are wrong on several points. > > Eliotte maybe has no infinite amount of time to work on Maven, but > whatever "triggers" him, he could find a more appropriate time and > place to expose what he found while "looking around" than a voting > thread, like for example a new thread on ML. > Second, I neither have an infinite amount of time to work on Maven, > but he just started spamming, seeing repositories having A LOT of > issues created by him... I certainly will not triage these, as others > said on this list, this is _mostly spam_. > > https://github.com/apache/maven-help-plugin/issues > https://github.com/apache/maven-shared-utils/issues > > Is this familiar to you from somewhere? > > Thanks > T > >> On Tue, 30 Jun 2026 at 23:18, David Jencks <[email protected]> wrote: >> >> I don’t actually work on maven, so feel free to discount my opinion. I don’t >> really understand your point of view. I doubt Elliotte has an infinite >> amount of time to work on maven, so I think he takes vote threads as a >> trigger to look around for possible problems and improvements in the release >> candidate and generally asks, “are any of these important enough to redo the >> release?” While this might seem annoying or distracting, upon reflection I >> think this is a valuable contribution. While I think this is the first time >> he’s used AI to look for problems, I think it’s conceptually similar to many >> of his past posts on vote threads. >> >> David Jencks >> Sent from my iPhone >> >>>> On Jun 30, 2026, at 1:33 PM, Hervé Boutemy <[email protected]> wrote: >>> >>> one day, you'll have to learn what voting means: such work is useful for >>> next release, not in a vote thread >>> >>>> On 2026/06/30 13:00:20 Elliotte Rusty Harold wrote: >>>> Another grab bag of bugs the LLM found. At first glance, none of these >>>> look too serious though: >>>> >>>> # Bug Analysis: maven-resolver >>>> >>>> Generated by code analysis of `/Users/elharo/maven-resolver` >>>> (v2.0.21-SNAPSHOT). >>>> >>>> --- >>>> >>>> ## HIGH Severity >>>> >>>> ### 1. NPE — `getClassLoader().getResource()` returns null >>>> **File:** >>>> `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:265` >>>> >>>> ```java >>>> String url = clazz.getClassLoader().getResource(className).toString(); >>>> ``` >>>> >>>> `ClassLoader.getResource()` returns `null` when the resource is not >>>> found, and `getClassLoader()` returns `null` for classes loaded by the >>>> bootstrap class loader. Either condition causes an NPE on >>>> `.toString()`. The method `getJarPath()` is called during client >>>> initialization to build the classpath for forking a child process. >>>> >>>> ### 2. NPE — `receive()` reads volatile `input` without synchronization >>>> **File:** >>>> `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:288-311` >>>> >>>> ```java >>>> void receive() { >>>> try { >>>> while (true) { >>>> int id = input.readInt(); // NPE here if input null >>>> ``` >>>> >>>> `input` is a volatile field (line 86). `receive()` reads it without >>>> holding the `IpcClient` monitor. Meanwhile, `close(Throwable)` (line >>>> 351, `synchronized`) sets `input = null` (line 360). Between the >>>> volatile read at line 291 and the `input.readInt()` call, another >>>> thread can call `close()`, nulling `input`. The same pattern applies >>>> to `send()` at line 316 with `output`. >>>> >>>> ### 3. NPE — `getAddress()` can NPE on `socket.getLocalAddress()` >>>> **File:** >>>> `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:447-453` >>>> >>>> ```java >>>> private String getAddress() { >>>> try { >>>> return SocketFamily.toString(socket.getLocalAddress()); >>>> } catch (IOException e) { >>>> return "[not bound]"; >>>> } >>>> } >>>> ``` >>>> >>>> `socket` is volatile (line 84) and set to `null` in `close()` (line >>>> 359). If `close()` runs concurrently with `toString()` (which calls >>>> `getAddress()`), `socket` is null and `socket.getLocalAddress()` >>>> throws NPE, which is **not** an `IOException` and is thus uncaught. >>>> >>>> ### 4. Resource leak — `BufferedReader` never closed in >>>> `parseMultiResource()` >>>> **File:** >>>> `maven-resolver-test-util/src/main/java/org/eclipse/aether/internal/test/util/DependencyGraphParser.java:161` >>>> >>>> ```java >>>> BufferedReader reader = new BufferedReader(new >>>> InputStreamReader(res.openStream(), StandardCharsets.UTF_8)); >>>> ``` >>>> >>>> The `BufferedReader` (and its underlying `InputStream`) is **never >>>> closed**. If `parse(reader)` throws an IOException, the stream leaks. >>>> Compare with the correctly-implemented `parse(URL)` method at line >>>> 174-188 which uses try-finally. >>>> >>>> --- >>>> >>>> ## MEDIUM Severity >>>> >>>> ### 5. Catching `Throwable` in non-framework code >>>> **File:** >>>> `maven-resolver-transport-jetty/src/main/java/org/eclipse/aether/transport/jetty/PutTaskRequestContent.java:246, >>>> 298` >>>> >>>> ```java >>>> } catch (Throwable t) { >>>> lockedSetTerminal(Content.Chunk.from(t, true)); >>>> } >>>> ``` >>>> >>>> Catches `OutOfMemoryError`, `StackOverflowError`, `InternalError`, >>>> etc. These should propagate. Wrapping them as terminal chunks converts >>>> fatal JVM errors into regular failure conditions, making them >>>> invisible to diagnostics. >>>> >>>> ### 6. Production error logging to `System.out` >>>> **File:** >>>> `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcServer.java:196` >>>> >>>> ```java >>>> private static void error(String msg, Throwable t) { >>>> System.out.println("[ipc] [error] " + msg); >>>> t.printStackTrace(System.out); >>>> } >>>> ``` >>>> >>>> All errors in the IPC server go to stdout instead of a proper logging >>>> framework (SLF4J). In a production Maven build, these messages are >>>> invisible or interleaved with build output. Same issue for `debug()` >>>> (line 184) and `info()` (line 190) in the same file. >>>> >>>> ### 7. Listener RuntimeException silently swallowed by default >>>> **Files:** >>>> - >>>> `maven-resolver-util/src/main/java/org/eclipse/aether/util/listener/ChainedRepositoryListener.java:117` >>>> - >>>> `maven-resolver-util/src/main/java/org/eclipse/aether/util/listener/ChainedTransferListener.java:118` >>>> >>>> ```java >>>> @SuppressWarnings("EmptyMethod") >>>> protected void handleError(...) { >>>> // default just swallows errors >>>> } >>>> ``` >>>> >>>> All `RuntimeException`s thrown by any chained listener (NPEs, >>>> `IndexOutOfBoundsException`, etc.) are silently swallowed unless the >>>> user subclasses and overrides `handleError`. This makes listener bugs >>>> invisible. >>>> >>>> ### 8. Volatile fields with inconsistent synchronization >>>> **File:** >>>> `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:78-87` >>>> >>>> Fields `initialized`, `socket`, `output`, `input`, `receiver` are >>>> `volatile` but their compound use (read + method call) lacks >>>> synchronization. `send()` reads `output` into a local variable at line >>>> 316 without holding the monitor, then synchronizes on the local >>>> reference at line 323, but `close()` nulls `output` under >>>> `synchronized(this)` at line 361. `receive()` has the same pattern >>>> with `input`. >>>> >>>> ### 9. SyncContext double-close risk >>>> **Files:** >>>> - >>>> `maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:189-190, >>>> 393-397, 430-432` >>>> - >>>> `maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java:142-143, >>>> 302-373` >>>> >>>> Two `SyncContext` instances (`shared` and `exclusive`) are created in >>>> try-with-resources. Inside `resolve()`, `current` starts as `shared`, >>>> and when switching to `exclusive` (line 393-396), `current.close()` is >>>> called, then `current = exclusive`. The outer try-with-resources also >>>> closes both on exit (line 202 for try-with-resources, and line 431 for >>>> the inner `current.close()`). While `SyncContext.close()` is >>>> documented as idempotent, any implementation that violates this >>>> contract would cause issues. >>>> >>>> ### 10. InterruptedException causes task to be silently dropped >>>> **File:** >>>> `maven-resolver-util/src/main/java/org/eclipse/aether/util/concurrency/SmartExecutor.java:177-179` >>>> >>>> ```java >>>> } catch (InterruptedException e) { >>>> Thread.currentThread().interrupt(); >>>> } >>>> ``` >>>> >>>> In `Limited.submit(Runnable)` (line 155), if `semaphore.acquire()` >>>> throws `InterruptedException`, the interrupt flag is restored but the >>>> caller's task is never executed. The method simply returns. The >>>> `submit(Callable)` variant (line 183-213) correctly handles this by >>>> returning a failed `CompletableFuture`. The `Runnable` overload should >>>> do something analogous (e.g., run the task inline or throw). >>>> >>>> --- >>>> >>>> ## LOW Severity >>>> >>>> ### 11. Minor resource leak in `parseLiteral()` >>>> **File:** >>>> `maven-resolver-test-util/src/main/java/org/eclipse/aether/internal/test/util/DependencyGraphParser.java:134-138` >>>> >>>> ```java >>>> BufferedReader reader = new BufferedReader(new >>>> StringReader(dependencyGraph)); >>>> DependencyNode node = parse(reader); >>>> reader.close(); // never reached if parse() throws >>>> ``` >>>> >>>> While `StringReader.close()` is a no-op, the pattern is inconsistent >>>> with the rest of the codebase and represents a latent bug if the >>>> implementation changes. >>>> >>>> ### 12. Empty catch swallows exceptions in `tryUnlock()` >>>> **File:** >>>> `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcNamedLock.java:108-115` >>>> >>>> ```java >>>> private void tryUnlock(String contextId) { >>>> try { >>>> client.unlock(contextId); >>>> } catch (Exception e) { >>>> // Best-effort cleanup >>>> } >>>> } >>>> ``` >>>> >>>> All exceptions from `unlock()` during timeout cleanup are silently >>>> discarded. While documented as intentional, this can mask real >>>> IO/connectivity issues. >>>> >>>> ### 13. Non-thread-safe access in synchronized `Results` class >>>> **File:** >>>> `maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegate.java:571-598` >>>> >>>> `addException()` and `addCycle()` are `synchronized` on `Results`, but >>>> they call `result.getExceptions()` and `result.getCycles()` on a >>>> `CollectResult` that may not be thread-safe. If `CollectResult`'s >>>> internal collections are not synchronized or safely published, >>>> concurrent modifications may not be visible. >>>> >>>> ### 14. `putIfAbsent()` fast-path race >>>> **File:** >>>> `maven-resolver-util/src/main/java/org/eclipse/aether/util/concurrency/ConcurrentWeakCache.java:124-146` >>>> >>>> ```java >>>> V existing = get(key); // fast path >>>> if (existing != null) { >>>> return existing; >>>> } >>>> ``` >>>> >>>> The fast-path `get()` uses a ThreadLocal `LookupKey`. Between `get()` >>>> returning null and `merge()` at line 135, another thread can insert a >>>> new value. The merge correctly handles this, but if `get()` returns a >>>> non-null reference to a key that gets GC'd immediately after, we >>>> return a stale reference. This is a correct-by-accident pattern — the >>>> merge would fix it, but we return early. >>>> >>>> ### 15. Pre-Java-7 stream handling in test utilities >>>> **Files:** >>>> - >>>> `maven-resolver-test-util/src/main/java/org/eclipse/aether/internal/test/util/TestFileUtils.java:172-325` >>>> - >>>> `maven-resolver-test-util/src/main/java/org/eclipse/aether/internal/test/util/TestFileProcessor.java:63-151` >>>> >>>> Methods manually close streams in try-catch-finally blocks instead of >>>> using try-with-resources. If an explicit `close()` call throws before >>>> the finally block, open resources are leaked. Functionally correct in >>>> happy-path but fragile. >>>> >>>> ### 16. `printStackTrace()` used instead of logging in tests >>>> Multiple test files use `e.printStackTrace()` instead of proper >>>> assertions or test framework logging, making test failures harder to >>>> diagnose. Affected files include: >>>> - >>>> `maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultArtifactResolverTest.java:740, >>>> 752, 805, 874, 975, 987` >>>> - `maven-resolver-demos/src/main/java/.../Booter.java:111` >>>> - >>>> `maven-resolver-api/src/test/java/org/eclipse/aether/DefaultSessionDataTest.java:118` >>>> - >>>> `maven-resolver-api/src/test/java/org/eclipse/aether/DefaultRepositoryCacheTest.java:82` >>>> >>>> --- >>>> >>>> ## Summary >>>> >>>> | Severity | Count | Key Areas | >>>> |----------|-------|-----------| >>>> | HIGH | 4 | IpcClient (3 NPEs), DependencyGraphParser (resource >>>> leak) | >>>> | MEDIUM | 6 | PutTaskRequestContent (Throwable catch), >>>> IpcServer (stdout logging), ChainedListener (silent swallow), >>>> IpcClient (sync), SyncContext double-close, SmartExecutor (dropped >>>> task) | >>>> | LOW | 6 | Minor resource leak, swallowed exception, thread >>>> safety in Results, ConcurrentWeakCache race, old stream handling, >>>> printStackTrace | >>>> >>>> The **IPC named-locks module** (`maven-resolver-named-locks-ipc`) >>>> accounts for the majority of HIGH-severity issues — it has multiple >>>> NPEs from unsynchronized volatile field access. >>>> >>>>> On Tue, Jun 30, 2026 at 8:09 AM <[email protected]> wrote: >>>>> >>>>> Hello Maven, >>>>> >>>>> I'd like to call a vote on releasing the following artifacts as >>>>> Apache Maven Resolver 2.0.20. This vote is being conducted using an >>>>> Alpha version of the Apache Trusted Releases (ATR) platform. >>>>> Please report any bugs or issues to the ASF Tooling team. >>>>> >>>>> The release candidate page, including downloads, can be found at: >>>>> >>>>> https://release-test.apache.org/vote/maven-resolver/2.0.20 >>>>> >>>>> The release artifacts are signed with one or more OpenPGP keys from: >>>>> >>>>> https://dist.apache.org/repos/dist/release/maven/KEYS >>>>> >>>>> Maven staging repository: >>>>> >>>>> https://repository.apache.org/content/repositories/maven-2440/ >>>>> >>>>> Release notes (draft): >>>>> >>>>> https://gist.github.com/cstamas/1a20ff11105992bf90a982cbae34036e >>>>> >>>>> Changes since the last release: >>>>> >>>>> https://github.com/apache/maven-resolver/compare/maven-resolver-2.0.18...maven-resolver-2.0.20 >>>>> >>>>> Staging site: >>>>> >>>>> https://maven.apache.org/resolver-archives/resolver-LATEST/ >>>>> >>>>> Site deployed to SVN; sync pending; SVN site source: >>>>> >>>>> https://svn.apache.org/repos/asf/maven/website/components/resolver-archives/resolver-LATEST/index.html >>>>> >>>>> Please review the release candidate and vote accordingly. >>>>> >>>>> [ ] +1 Release this package >>>>> [ ] +0 Abstain >>>>> [ ] -1 Do not release this package (please provide specific comments) >>>>> >>>>> You can vote on ATR at the URL above, or manually by replying to this >>>>> email. >>>>> >>>>> The vote is open for 72 hours. >>>>> >>>>> >>>>> Thanks, >>>>> Tamas Cservenak (cstamas) >>>>> >>>>> This email was sent by [email protected] on the Apache Trusted Releases >>>>> platform >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> >>>> -- >>>> Elliotte Rusty Harold >>>> [email protected] >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
