Handle RUNFILES_DIR and/or RUNFILES_MANIFEST_FILE in java_stub_template.txt

[ar3s3ru]

Description of the feature request:

The current implementation of java_stub_template.txt, used in java_binary, requires JAVA_RUNFILES to be present in the environment:

bazel/src/main/java/com/google/devtools/build/lib/bazel/rules/java/java_stub_template.txt

Lines 159 to 187 in 492ee4c

	if [[ -z "$JAVA_RUNFILES" ]]; then
	while true; do
	if [[ -e "$self.runfiles" ]]; then
	JAVA_RUNFILES="$self.runfiles"
	break
	fi
	if [[ $self == *.runfiles/* ]]; then
	JAVA_RUNFILES="${self%.runfiles/*}.runfiles"
	break
	fi
	if [[ ! -L "$self" ]]; then
	break
	fi
	readlink="$(readlink "$self")"
	if [[ "$readlink" = /* ]]; then
	self="$readlink"
	else
	# resolve relative symlink
	self="${self%/*}/$readlink"
	fi
	done
	if [[ -n "$JAVA_RUNFILES" ]]; then
	export TEST_SRCDIR=${TEST_SRCDIR:-$JAVA_RUNFILES}
	elif [[ -f "${self}_deploy.jar" && "%needs_runfiles%" == 0 ]]; then
	SINGLEJAR=1;
	else
	die 'Cannot locate runfiles directory. (Set $JAVA_RUNFILES to inhibit searching.)'
	fi
	fi

At the very least, it should also support the newer RUNFILES_DIR variable.

Additionally, the script could also gracefully handle having RUNFILES_MANIFEST_FILE in the env over RUNFILES_DIR or JAVA_RUNFILES.

Which category does this issue belong to?

Java Rules

What underlying problem are you trying to solve with this feature?

No response

Which operating system are you running Bazel on?

Darwin

What is the output of bazel info release?

release 6.4.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

Issue was highlighed while trying to solve bazel-contrib/rules_jvm#211 through bazel-contrib/rules_jvm#224.

More context on Bazel Slack: https://bazelbuild.slack.com/archives/C01HMGN77Q8/p1701887957242259

[peakschris]

There is a related issue here. If one java_binary invokes a second java_binary through system call, the second java_binary should run correctly, even though its environment is inherited from the first. This means that really the first java_binary invokation should succeed even without RUNFILES environment variables having been set.

[peakschris]

Currently, the second java_binary fails, as its JAVA_RUNFILES and RUNFILES_DIR env vars are inherited from the first process and point to the wrong thing.