On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bjørsnøs <[email protected]> wrote:
> Please review this PR which proposes we replace `j.u.ArrayDeque` with
> `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`.
>
> The motivation for using a double-ended queue may have been that "original"
> search path URLs are added to the tail of the queue while any "loader
> discovered" class path URLs are inserted at the head such that they are
> processed first.
>
> By splitting these two concerns and processing loader discovered class path
> URLs separately from the original search path, we no longer need a
> double-ended queue. We can replace `ArrayDeque` with `ArrayList`.
>
> Advantages:
>
> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and
> `Queue` (`URLClassPath` is the only consumer of these classes during startup)
> * One data structure is simpler than two
> * We no longer need to manage search path URLs across two different
> collections
> * Code and comments to dance around `ArrayDeque` calling into lambda too
> early is no longer a concern and can be removed
> * I think this PR leaves the code overall simpler and easier to follow.
>
> Testing:
>
> This PR introduces a new test to verify that URLs disovered via a multi-level
> tree paths discovered via `Class-Path` JAR attributes are found in the
> expected DFS order. The ordering aspect seems to lack existing coverage.
This PR now includes a test to verify DFS search order of a multi-level tree of
JARs related by `Class-Path` attributes.
Current testing verifies basic `Class-Path` functionality, but does not catch
regressions introduced by subtle changes in ordering.
src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 403:
> 401: while (loaders.size() < index + 1) {
> 402: final URL url;
> 403: synchronized (searchPath) {
@liach Do you think it would be prudent to fold the synchronization here into
`nextURL`?
This way `nextURL()` would claim full responsibility for its own accesses and
we could remove the note on holding the lock when calling the method?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3765753966
PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2705168431
