Re: RFR: 8370100: Redundant .png files in Linux app-image cause unnecessary bloat [v2]

[Alexey Semenyuk]

On Mon, 27 Oct 2025 22:33:57 GMT, Alexander Matveev <almat...@openjdk.org> 
wrote:

>> This is the same task but with a disabled action. Task graph doesn't allow 
>> multiple tasks with the same ID.
>> 
>> By default, the `LAUNCHER_ICONS` task copies launcher icon files to the app 
>> image. However, when bundling a native package, this action should not be 
>> executed because the `DesktopIntegration` class adds launcher icons to the 
>> package.
>> 
>> Before this change, jpackage copied launcher icon files twice when building 
>> a native package: in `LAUNCHER_ICONS` task and in `DesktopIntegration` class.
>> 
>> Function name `add()` is confusing. Should be `apply()` or `commit()`.
>
> Thanks for explanation. Make sense now. Should we do something like:
> 
> if (pkg.isEmpty()) {
> .task(LinuxAppImageTaskID.LAUNCHER_ICONS)
>                         .addDependent(BuildApplicationTaskID.CONTENT)
>                         
> .applicationAction(LinuxPackagingPipeline::writeLauncherIcons).add();
> }
> 
> Add task only for application image vs adding it always and then overwriting 
> with noaction()?

We can do this, but this will complicate building the task graph by making the 
set of nodes and edges conditional.

It is simpler to build the graph unconditionally, but configure actions for the 
nodes conditionally.

E.g.: mac packaging task graph is way more sophisticated in terms of branching, 
see - 
[MacPackagingPipeline.build()](https://github.com/openjdk/jdk/blob/2f613911d58478913dc482e1500d3fbab74408b9/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java#L104).
 but its initialization is quite stratighforward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27928#discussion_r2467352699