Replace HostPlatform with Gradle BuildPlatform service

[AlexeyKuznetsov-DD]

What Does This Do

Replaces the custom HostPlatform helper (which read os.name/os.arch system properties) with Gradle's BuildPlatform, obtained from the injectable CurrentBuildPlatform service via serviceOf.

Motivation

Follow-up to a review note on #11364: prefer Gradle's platform detection over hand-rolled system-property string matching.

Additional Notes

Helper functions make this PR looks better.

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	14.00 s	13.98 s	[-0.4%; +0.8%] (no difference)
startup:insecure-bank:tracing:Agent	12.96 s	13.00 s	[-1.1%; +0.5%] (no difference)
startup:petclinic:appsec:Agent	16.82 s	16.53 s	[+0.8%; +2.7%] (maybe worse)
startup:petclinic:iast:Agent	16.78 s	16.84 s	[-1.2%; +0.5%] (no difference)
startup:petclinic:profiling:Agent	16.72 s	16.27 s	[-1.8%; +7.2%] (no difference)
startup:petclinic:sca:Agent	16.81 s	16.62 s	[+0.2%; +2.1%] (maybe worse)
startup:petclinic:tracing:Agent	15.61 s	15.64 s	[-6.1%; +5.7%] (unstable)

Commit: a4d701e8 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[bric3]

I'm not quite convinced this gives any useful benefit. It appears to trade a simple property check in HostPlatform with a Gradle service, which means it needs to be queried from a project service.

Also, I would avoid making Gradle Groovy script import BuildPlatformExtensionsKt.

[AlexeyKuznetsov-DD]

I'm not quite convinced this gives any useful benefit. It appears to trade a simple property check in HostPlatform with a Gradle service, which means it needs to be queried from a project service.

Also, I would avoid making Gradle Groovy script import BuildPlatformExtensionsKt.

@bric3
Not sure 100%, but Gradle BuildPlatform is almost the same as HostPlatform:

• It uses Gradle functionality.
• Kotlin helpers makes code readable.
• Groovy code will be migrated to Kotlin one day (so that resolves: avoid making Gradle Groovy script import BuildPlatformExtensionsKt.)

Since you have a better Gradle expertise, I will let you decide on this PR.
Feel free to close or merge (or let me know you final decision).

[bric3]

It uses Gradle functionality.

But this functionality is incubating, and currently accessed through an internal service. If we didn't had any other option that would be OK, but we do.

Kotlin helpers makes code readable.

Clearly.

Adn probably fine in Kotlin as well, but I feel they are weird in groovy dsl, but that's mostly csometic. And as you said at some point it will be migrated to kotlin.

One thing that comes to mind is I need to check is whether accessing the project instance in some places is the right thing to do for configuration cache.

Not sure 100%, but Gradle BuildPlatform is almost the same as HostPlatform:

In the end that's precisely my point, I don't see any useful benefit. HostPlatform was fine, and simpler, while the internal gradle service is a bit of uncertainty (which is OK if there's no choice).

That said I don't see any strong point against either (maybe the possible issue with configuration cache, e.g. if the method is used at the wrong place and happens to inject the project instance, but I'm unsure).

[AlexeyKuznetsov-DD]

Closed PR, as there no clear benefit from the change. We can reconsider later.