On Wed, 21 Jan 2026 09:26:31 GMT, Claes Redestad <[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. > > FWIW `ArrayDeque` is likely to be loaded early regardless of these changes. I > ran this through some of our startup tests and noticed that in the typical > case we're net neutral and are just shifting the point of load from > URLClassPath to ZipFile.CleanableResource. You might see a reduction on tests > that load and run only classes which are not packed into jar files. > > Still, I think it's useful to reduce the complexity of the class load graph > in the earliest loaded classes. Any step in that direction removes trip-wires > and hazards for the primordial setup. Since this PR was marked to require two reviewers, then three for an area expert, we are now in the situation where it seems we need @cl4es and @liach to re-review before we can integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3804497181
