The JavaExecHandleBuilder generates invalid Class-Path entries

[joakime]

Current Behavior

When on windows, the behavior in JavaExecHandleBuilder to create Class-Path entries in the jar manifest is useful effort.

See #10544 and #10114

But the code in the master branch generates the entries with absolute URLs

gradle/subprojects/core/src/main/java/org/gradle/process/internal/JavaExecHandleBuilder.java

Lines 405 to 411 in 84a06b8

	private static Manifest toManifest(FileCollection classPath) {
	Manifest manifest = new Manifest();
	Attributes attributes = manifest.getMainAttributes();
	attributes.put(Attributes.Name.MANIFEST_VERSION, "1.0");
	attributes.putValue("Class-Path", classPath.getFiles().stream().map(File::toURI).map(URI::toString).collect(Collectors.joining(" ")));
	return manifest;
	}

This is not what the JAR spec allows for the Class-Path attribute.

See: https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html#class-path-attribute

Those entries are supposed to be relative URL reference to the context of the jar file that contains those entries.

The absolute URL references are not considered valid.

See bullet point 2 of the above referenced javadoc (copy/pasted here)

A Class-Path entry is valid if the following conditions are true:

• It can be used to create a URL, by resolving it against the context JAR’s URL.
• It is relative, not absolute, i.e. it does not contain a scheme component, except for the case when the context JAR is loaded from the file system, in which case the file scheme is permitted for compatibility reasons.
• The location of the JAR file or directory represented by this entry is contained within the containing directory of the context JAR. Use of "../" to navigate to the parent directory is not permitted, except for the case when the context JAR is loaded from the file system.

Invalid entries are ignored. Valid entries are resolved against the context JAR. If the resulting URL is invalid or refers to a resource that cannot be found, then it is ignored. Duplicate URLs are ignored.

Expected Behavior

The Class-Path entries should be generated as relative URL references to the JAR file that has those entries.

Context (optional)

No response

Steps to Reproduce

See examples at

• https://stackoverflow.com/q/77055635/775715
• https://stackoverflow.com/q/77017801/775715

Gradle version

all

Build scan URL (optional)

No response

Your Environment (optional)

No response

[ov7a]

Sorry that you're having trouble with Gradle!

We appreciate the effort that went into filing this issue, but we must ask for more information.

As stated in our issue template, a minimal reproducible example is a must for us to be able to track down and fix your problem efficiently. Our available resources are severely limited, and we must be sure we are looking at the exact problem you are facing.

If we have a reproducer, we may be able also to suggest workarounds or ways to avoid the problem.

The ideal way to provide a reproducer is to leverage our reproducer template. You can also use Gradle Project Replicator to reproduce the structure of your project.

This issue will be closed after 7 days unless you provide more information.

---

While you provided us a great explanation about why it might be a problem, we want to be 100% sure that this is a problem in practice.

[joakime]

While you provided us a great explanation about why it might be a problem, we want to be 100% sure that this is a problem in practice.

There are 2 open questions that show the problem in practice on stackoverflow right now.
Both have examples, and logs, and details of the manifest.

• https://stackoverflow.com/q/77055635/775715
• https://stackoverflow.com/q/77017801/775715

Both happen to be on Windows.

I'm an Eclipse Jetty committer, and was helping these users of gradle diagnose why their environments were not starting up properly.
Once I saw their Class-Path entry, I remembered my days back as a committer on Apache Maven and saw that your code is doing what Apache Maven used to do (full URLs). This is a known problem, and the JVM will just ignore those entries in the Class-Path if the URL is absolute.

This is especially a problem on windows, as the multiple drive roots (C:/ vs D:/) trigger bugs in relative URL path reference quite easily on windows (and never on Linux/Unix).

[ov7a]

I agree that your analysis is great. However, could you please provide a reproducer which demonstrates the issue in isolation? The issues you're pointing at contain some steps, sure, however, we're not 100% sure that the problem is caused by Gradle and not some integration issues.

[joakime]

Do you have an example project that uses JavaExecHandleBuilder that I can build a reproducer from?

If you ask me to build one, it's going to require a Windows box with multiple drive letters accessible from Java.

[ov7a]

No, we don't have such a template. I think you can use the SO questions you mentioned and adapt the basic template I mentioned before. Creating a custom task with create<JavaExec> should be enough to reach JavaExecHandleBuilder.

We don't provide Windows boxes. I believe Microsoft has some free images available for testing.

[github-actions]

While we asked for a reproducer, none was provided. If you provide a valid reproducer, we will consider this issue again. In the meantime, closing as unreproducible.