On Wed, 16 Jul 2025 15:31:07 GMT, David Beaumont <d...@openjdk.org> wrote:

>> Refactoring `ImageReader` to make it easy to add preview mode functionality 
>> for Valhalla.
>> 
>> This PR is a large change to `ImageReader` (effectively a rewrite) but 
>> reduces the surface area of the API significantly, reduces code complexity 
>> and increases performance/memory efficiency. The need for this sort of 
>> change comes from the need to support "preview mode" in Valhalla for classes 
>> loaded from core modules.
>> 
>> ### Preview Mode
>> 
>> In the proposed preview mode support for Valhalla, a resource with the name 
>> `/modules/<module>/<path>` may come from one of two locations in the 
>> underlying jimage file; `/<module>/<path>` or 
>> `/<module>/META-INF/preview/<path>`. Furthermore, directories (represented 
>> as directory nodes via the API) will have a potentially different number of 
>> child nodes depending on whether preview mode is in effect, and some 
>> directories may only exist at all in preview mode.
>> 
>> Furthermore, the directories and symbolic link nodes in `/packages/...` will 
>> also be affected by the existence of new package directories. To retain 
>> consistency and avoid "surprises" later, all of this needs to be taken into 
>> account.
>> 
>> Below is a summary of the main changes for mainline JDK to better support 
>> preview mode later:
>> 
>> ### 1: Improved encapsulation for preview mode
>> 
>> The current `ImageReader` code exposes the data from the jimage file in 
>> several ways; via the `Node` abstraction, but also with methods which return 
>> an `ImageLocation` instance directly. In preview mode it would not be 
>> acceptable to return the `ImageLocation`, since that would leak the 
>> existence of resources in the `META-INF/preview` namespace and lets users 
>> see resource nodes with names that don't match the underlying 
>> `ImageLocation` from which their contents come.
>> 
>> As such, the PR removes all methods which can leak `ImageLocation` or other 
>> "underlying" semantics about the jimage file. Luckily most of these are 
>> either used minimally and easily migrated to using nodes, or they were not 
>> being used at all. This PR also removes any methods which were already 
>> unused across the OpenJDK codebase (if I discover any issues with 
>> over-trimming of the API during full CI testing, it will be easy to address).
>> 
>> ### 2. Simplification of directory child node handling
>> 
>> The current `ImageReader` code attempts to create parent directories "on 
>> demand" for any child nodes it creates. This results in parent directories 
>> having a non-empty but incomplete set of child nodes present. This is re...
>
> David Beaumont has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains one commit:
> 
>   Resync after benchmark.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 28:

> 26: 
> 27: import java.io.IOException;
> 28: import java.io.UncheckedIOException;

Unused, can be removed

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 279:

> 277:         }
> 278: 
> 279:         /// Returns a node in the JRT filesystem namespace, or null if 
> no resource or

Using the standard javadoc tags for @param, @return can give some consistency 
and readability even for internal methods.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 532:

> 530:     public abstract static class Node {
> 531:         private final String name;
> 532:         private final BasicFileAttributes fileAttrs;

It seems a bit wasteful to cache the same attributes in every Node.
But its no more expensive (size-wise) than a referernce to the ImageReader and 
the indirection.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 543:

> 541:         // As such, non-directory nodes are always complete.
> 542:         boolean isCompleted() {
> 543:             return true;

Seems like a risky default to have this be a concrete method/default that is 
not required to be overridden.
A subclass (not that many here) could forget to override and have a default 
wrong answer. YMMV.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 611:

> 609:          *
> 610:          * <p>If this node is not a directory ({@code isDirectory() == 
> false})
> 611:          * then this method will throw {@link IllegalStateException}.

A mismatch in overriding could give inconsistent results (since the impl does 
not call `isDirectory()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216403082
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216447991
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216510819
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216472104
PR Review Comment: https://git.openjdk.org/jdk/pull/26054#discussion_r2216478048

Reply via email to