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

[Eirik Bjørsnøs]

On Sat, 17 Jan 2026 21:56:05 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 URLs discovered during JAR `Class-Path` expansion 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.

I'll wait for Jai or others who have visited this class in the past.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3776308166