Implement the wrapper as a single Java file using JEP 330

[Pankraz76]

Implement the wrapper as a single Java file using JEP 330

crediting @hegyibalint, by coping:

• Implement the Gradle wrapper as a single Java file using JEP 330 gradle/gradle#35638

Expected Behavior

JEP 330 opened a new way of conveniently running a Java source file (e.g, java MySourceFile.java). We could use this mechanism to provide a readable entry point for how Gradle is launched.

When the wrapper would change—next to the SHA change—the textual, reviewable content of the wrapper could help users gain confidence that the changes can be trusted.

Current Behavior (optional)

The Gradle wrapper is a binary JAR. Checking binaries into repositories is often frowned upon, and considered not best practice. Despite this, Gradle chose to still go with this to provide convenience to the users; nowadays committing the wrapper became a widespread and accepted practice. We additionally have sha256 checksums for the wrappers, making sure the content is the same as expected.

However, the fact that the wrapper is a binary still poses some issues and friction with people. It's not easy to diff, and it's not easy to see what it does.

Context

There were several conversations about this, touching on these points:

• Don't make gradle-wrapper.jar a default part of a new project #25784
• Bootstrap Gradle build using cmd-line scripts only #11816

However, we believe this issue makes sense as a more exact way to improve the situation.

related to:

• [rewrite] Add UpdateMavenWrapper google/error-prone#5343

[Pankraz76]

might be an inspiration for this one as well.

seems to be related.

[cstamas]

Seems interesting...