8346669: Increase abstraction in SetupBuildLauncher and remove extra args

[magicus]

We need to raise the abstraction of the SetupBuildLauncher API, to prepare for static launchers. We should specify the desired outcome, not what flags we should add. This can be seen as the last part of JDK-8141444 (9 years later).

In the process, I am removing EXTRA_JAVA_ARGS which has not been used for a long time. I also removed this part from the launcher itself.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8346669: Increase abstraction in SetupBuildLauncher and remove extra args (Bug - P3)

Reviewers

• Erik Joelsson (@erikj79 - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22832/head:pull/22832
$ git checkout pull/22832

Update a local copy of the PR:
$ git checkout pull/22832
$ git pull https://git.openjdk.org/jdk.git pull/22832/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 22832

View PR using the GUI difftool:
$ git pr show -t 22832

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22832.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ihse! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@magicus This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8346669: Increase abstraction in SetupBuildLauncher and remove extra args

Reviewed-by: erikj

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 24 new commits pushed to the master branch:

• bcb1bda: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path
• 054c644: 8346667: Doccheck: warning about missing before

• 2a68f74: 8346128: Comparison build fails due to difference in LabelTarget.html
• cf28fd4: 8322983: Virtual Threads: exclude 2 tests
• 85e024d: 8346605: AIX fastdebug build fails in memoryReserver.cpp after JDK-8345655
• 54f3475: 8331467: FileSystems.getDefault fails with ClassNotFoundException if custom default provider is in run-time image
• 35fafbc: 8346106: Verify.checkEQ: testing utility for recursive value verification
• b2811a0: 8340493: Fix some Asserts failure messages
• 4d77dba: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from test/hotspot/jtreg/ProblemList.txt
• 2649a97: 8332827: [REDO] C2: crash in compiled code because of dependency on removed range check CastIIs
• ... and 14 more: https://git.openjdk.org/jdk/compare/73b5dbaec340b3e8c958d63f510df92ec621c04e...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@magicus The following labels will be automatically applied to this pull request:

• build
• compiler
• core-libs
• hotspot-jfr
• kulla

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[magicus]

/label -kulla -hotspot-jfr -compiler

[openjdk]

@magicus
The kulla label was successfully removed.

The hotspot-jfr label was successfully removed.

The compiler label was successfully removed.

[mlbridge]

Webrevs

• 00: Full (f5f2a3ec)

[erikj79]

I'm not convinced this level of abstraction makes things better. It adds quite a bit of overhead for adding additional customization options for when adding new launchers. Could you elaborate more on why this is needed?

[erikj79]

What happened to all of these? Were they never needed?

[magicus]

I don't know. If so, it was a long time ago.

Hm, maybe it was from when JLI was statically linked. It could actually be that we still need something like:

LIB_aix := $(LIBZ_LIBS), \

Perhaps someone from the AIX team can check this?

[magicus]

I'm not convinced this level of abstraction makes things better. It adds quite a bit of overhead for adding additional customization options for when adding new launchers. Could you elaborate more on why this is needed?

I could have been more clear at describing the end goal here. I have now opened https://bugs.openjdk.org/browse/JDK-8346719 for this. I have a prototype that implements the full functionality, with both the changes in this PR and the ones needed for JDK-8346719, but I thought it would be better to separate it into two steps -- one refactoring step of the existing code, and one adding the new functionality.

The core idea of JDK-8346719 is that we need to generate a command line to pass to the static java launcher. This means we need to know what the user is trying to accomplish with this particular launcher, not how they think it should be achieved. Even long before this became an issue for the static linkers, I still think this should have been done. We've worked hard to raise the abstraction level in the entire build system all the time, to describe the desired goal, not the assumed way of doing it. The fact that this was left out of JDK-8141444 all those years ago, was just due to lack of time back then. That change started doing this kind of abstraction level raising for the launchers, and then it has never been prioritized to be revisited, until now.