RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath

Chen Liang liach at openjdk.org
Mon Jan 19 17:45:02 UTC 2026


On Mon, 19 Jan 2026 15:15:18 GMT, Eirik Bjørsnøs <eirbjo at openjdk.org> 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


More information about the core-libs-dev mailing list