[lworld] RFR: 8368467: [lworld] Add new flag generation for jimage to support preview mode [v3]

[David Beaumont]

On Wed, 5 Nov 2025 21:39:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback and test fix
>
> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 177:
> 
>> 175:      * @return package flags for {@code "/packages/xxx"} directory entries.
>> 176:      */
>> 177:     public static int getPackageFlags(List<ModuleReference> moduleReferences) {
> 
> This exclusively works on ModuleReferences, it seems that it should be in ModuleReference, not ImageLocation. It is only in ImageLocation because the flags are private.
> And it is only used by ImageResourceTree, so should be there.
> There has to be a better structure that doesn't cause so much confusion and crossing boundaries.
> And yes, I think it is another example where having similar but different flags is harmful to the structure and meaning of the code.

As you point out, the flags are private, so I'd have to change that in some way to move this function elsewhere.
It does operate on module references, but only via their public API (which doesn't require those flags to be public).
As I've said, the flags are similarly named because they have similar semantics. They cannot really share the same constant values because of the differing requirements for each (personally I'd also say it's better if flags stored in different places are different constants).
The most natural place to find it would be ImageResourceTree, and I can do that if we make the ImageLocation flags public (the ModuleReference flags can stay private of course).
Does that sound okay?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2498770042