On Mon, 19 Jan 2026 15:15:18 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.
>
> 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?
Sure!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2705526483
