From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

If you run `sysctl sysctl.proc_translated` in your terminal do you get the same result?

nope :disappointed:

```% sysctl sysctl.proc_translated
sysctl.proc_translated: 0```

And if you add `System.getProperty("os.arch")` to your debugging plugin?

```&gt; Configure project :
sysctl.proc_translated: 1
aarch64```

I don't know how to recreate it, but you are running with the correct JDK and your process is translated for some reason
Can you try running something like `pstree -p &lt;pid&gt;` on the Java process and see which parent is the first to run with rosetta?
You can get the list of processes through `fuser /usr/libexec/rosetta/runtime`

I can recreate it, if I start a Gradle Daemon under rosetta, then Gradle will happily re-use that daemon even outside rosetta :grimacing:

:open_mouth:

```% jps                                                                              
49298 Jps
49231 GradleDaemon```
but 49231 is not listed under `fuser /usr/libexec/rosetta/runtime`

the `gitlab-runner` executable though is run with rosetta…could that be the issue?

You could also check to what `JAVA_HOME` environment variable is set, because if it is set, that is what is used, not the one in `PATH`.

You can also run with `--version` or `--show-version` to display which Java is used to run Gradle.

<@URQ797WRW> will that help with universal binaries?

The Java executable itself is not universal, or is it?

it is

```file $(which /usr/bin/java)               
/usr/bin/java: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/java (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/java (for architecture arm64e):	Mach-O 64-bit executable arm64e```

and there is no `JAVA_HOME`  set

``` % echo $JAVA_HOME```

```% ./gradlew --version

------------------------------------------------------------
Gradle 8.4
------------------------------------------------------------

Build time:   2023-10-04 20:52:13 UTC
Revision:     e9251e572c9bd1d01e503a0dfdf43aedaeecdc3f

Kotlin:       1.9.10
Groovy:       3.0.17
Ant:          Apache Ant(TM) version 1.10.13 compiled on January 4 2023
JVM:          17.0.7 (Eclipse Adoptium 17.0.7+7)
OS:           Mac OS X 13.5.2 aarch64```

Then I *guess* it indeed is
&gt; the `gitlab-runner` executable though is run with rosetta…could that be the issue?

I have the same feeling. This is using a shell executor and maybe the process in the plugin is executed inside a process spawn from the runner itself?