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 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 > using a directory class path) > * 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 pull request has now been integrated. Changeset: ca95e5f3 Author: Eirik Bjørsnøs <[email protected]> URL: https://git.openjdk.org/jdk/commit/ca95e5f3ddd5961dd43f825ed6c47054284c6798 Stats: 248 lines in 2 files changed: 205 ins; 20 del; 23 mod 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath Reviewed-by: liach, redestad, jpai ------------- PR: https://git.openjdk.org/jdk/pull/29288
