Process isolated workers always use system default encoding for file names

[ghale]

When we spawn worker processes when using process isolation with the worker API, the environment of the spawned process is scrubbed. We do set the file.encoding system property by default, but this only affects the contents of files. File names, on the other hand, are interpreted by the underlying native library of the JVM which relies on the locale (e.g. "LANG" environment variable) to define the effective charset. In the absence of any environment variables, it will use whatever the default is for the operating system and file system.

When passing a file property as a parameter and the file name contains UTF-8 characters, if locale environment variables are set for the build process, this can lead to a mismatch between the encoding used when interpreting the filename between the build process and the worker process leading to a FileNotFoundException when the worker process tries to access the file.

Explicitly setting the LANG environment variable in the worker process configuration resolves the issue. So, one solution would be to set the LANG environment variable in worker processes to whatever has been set in the build process.

Expected Behavior

Worker processes should use the same encoding for file names as the build process unless explicitly changed by the user.

Current Behavior

Worker processes may or may not use the same encoding for file names as the build process.

Context

This came up in the context of the Android team configuring their Jacoco task to use the worker api. They are passing the name of the file to instrument as a worker api file property parameter. They have a test that uses non-ASCII characters in the filename. On Linux, the build process has UTF-8 encoding, the worker process gets spawned with a null value for the LANG environment variable, and so the filename gets interpreted with the default encoding, which is something else (might be ASCII, might be ISO-8859, not sure) leading to a FileNotFoundException.

Steps to Reproduce

See 2ce3189

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[stale]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to to let know so we can reopen the issue. Please try to provide steps to reproduce, a quick explanation of your use case or a high-quality pull request.

[lptr]

Fixed by #25319