Allow custom target directory for exploding `jdkFile` into

Description: Introduce an optional input for specifying a custom target directory for exploding a jdkFile into.

Justification: Installing multiple JDKs that share the same JDK feature release number (like 19) is not possible at the moment.

For example, after downloading two JDK archives that both are based on JDK 19, the second run of setup-java@v3 detects that a Java 19 is already installed and uses it; instead of extracting the second JDK archive into a new and different directory:

    - name: 'Install custom JDK 19'
      uses: actions/setup-java@v3
      with:
        distribution: jdkfile
        jdkFile: .../openjdk-19-jextract+2-3_linux-x64_bin.tar.gz
        java-version: 19.0.0+0-jextract

    - name: 'Install full JDK 19'
      uses: actions/setup-java@v3
      with:
        distribution: jdkfile
        jdkFile: .../openjdk-19-ea+33_linux-x64_bin.tar.gz
        java-version: 19

The output of the second run reads like:

Run actions/setup-java@v3
  with:
    java-version: 19
    distribution: jdkfile
    jdkFile: .../openjdk-19-ea+33_linux-x64_bin.tar.gz
    java-package: jdk
    architecture: x64
    check-latest: false
    server-id: github
    server-username: GITHUB_ACTOR
    server-password: GITHUB_TOKEN
    overwrite-settings: true
    job-status: success
  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_jdkfile_jdk/19.0.0-0-jextract/x64
Resolved Java 19.0.0+0-jextract from tool-cache
Setting Java 19.0.0+0-jextract as default

Expectation:

With a custom target directory specified for each run (openjdk-19-jextract+2-3 and openjdk-19-ea+33), there would be two dedicated JDK installations. Like:

• /opt/hostedtoolcache/Java_jdkfile_jdk/openjdk-19-jextract+2-3/x64
• /opt/hostedtoolcache/Java_jdkfile_jdk/openjdk-19-ea+33/x64

Work-around: Pass fake values to java-version in order to generated dedicated target directories. See https://github.com/oracle-actions/setup-java/issues/34 for details.

[sormuras]

In fact, it does work already today, when choosing valid (SemVer-wise) but weird values like: 0 or 123 or Math.abs("abc...xyz".hashCode()). Yet, the output of which Java version is installed reads … weird:

… Java 862414701 was not found in tool-cache. Trying to unpack JDK file... … Setting Java 862414701 as default

Java configuration:
 Distribution: jdkfile
 Version: 862414701
 Path: /opt/hostedtoolcache/Java_jdkfile_jdk/862414701/x64

If input java-version would allow arbitrary (legal, file system-wise) values in jdkFile mode, it would help both cases, I guess.

[denismakogon]

@dsame I’m deeply sorry, but what Christian provided isn’t a “solution” but a workaround we have come up with.

You’re closing this because of what? What motivates you to leave “an elephant in a room” (a bug in setup-java action)? You really think that this is how it should work? I’m sorry to say but that’s not a technical conclusion rather than an attempt to avoid the decisions that action doesn’t work as it should be.