You usually don’t need any installed Gradle version anyway, as practically any Gradle project should include the four Gradle wrapper files to execute the build with a well-defined consistent Gradle version and you can bootstrap a new Gradle project either using the IDE or the Gradle wrapper of another project.
But besides that, you made not clear what your problem is, except that executing apt-get install gradle --dry-run outputs the same text if you run it twice. Is there something in those files you intended to share and didn’t?
Could you, please, “uncultured” your statements (it is not obvious, easy; I learned to do that when I became a teacher), functionally explaining (or pointing to an explanation of) what:
“include” means (included in your PATH variable in Linux (so that is is reachable by other programs)?)
which ones are the “four Gradle wrapper” (I thought there was only one since in the documentation they talk about “The Gradle Wrapper class” : “Gradle Wrapper”)?
Let me give myself a taste of my own medicine: when you run the Debian/Linux package installer with the “–dry-run” option it will show to you what it would do, or attempt to, in the background.
After I specified JAVA_HOME and included its JDK in the PATH, it should have “noticed” that java was already installed and used that (newer) version. I know it is not exactly a problem with gradle per se. I am just explaining what I was seeking with that dry run.
Why would gradle still attempt to download and install jdk 11 after I specified a newer version?
Gradle does not do.
What you called is an apt-get call, the older form of doing apt calls.
That is the package manager of your Linux distribution.
Whoever manages that Gradle package for that Linux distribution defines what packages it depends on.
If you do not have a package installed, but installed that newer Java manually, or installed a Java package that does not provide what that Gradle package is declaring as dependency, then the package manager is not happy with your newer Java.
But that is purely a topic for your package repository if you try to install Gradle from that package repository.
Alternatively, you can just download and unpack the official Gradle distribution manually as described at Gradle | Installation,
or just not install a Gradle version at all as mentioned before.
Could you, please, “uncultured” your statements
Unfortunately not, as I have no idea what you want from me, sorry. I’m not a native speaker.
“include” means (included in your PATH variable in Linux (so that is is reachable by other programs)?)
“include”, as having them, added to version control, or the source zip or however the projects sources is distributed.
which ones are the “four Gradle wrapper” (I thought there was only one since in the documentation they talk about “The Gradle Wrapper class” : “The Gradle Wrapper”)?
Not “four Gradle wrapper”, “four Gradle wrapper files”. You already linked to the exact documentation that explains it and also explicitly lists and explains the four files project sources should have with them (“include”).
After I specified JAVA_HOME and included its JDK in the PATH, it should have “noticed” that java was already installed and used that (newer) version.
Gradle itself would just use the Java from your JAVA_HOME or as fallback from PATH (given you use a version that is compatible with your Gradle version, otherwise it will most likely fail to execute later on).
But as explained above, the package manager does not care about what environment variables might be set. It just cares about installed packages and declared dependencies between these packages.