[Question] How to specify JAVA_VERSION

[emirot]

Not sure how to specify that I'm using JAVA 11. It's taking by default 8

$ lsif-java index
Using JVM version '8'
$ /builds/springboot-sandbox/gradlew --init-script /tmp/lsif-java7756353260882540485/java-toolchains.gradle lsifDetectJavaToolchains
Downloading https://services.gradle.org/distributions/gradle-6.8.3-bin.zip
..........10%..........20%..........30%...........40%..........50%..........60%..........70%...........80%..........90%..........100%
Welcome to Gradle 6.8.3!
Here are the highlights of this release:
 - Faster Kotlin DSL script compilation
 - Vendor selection for Java toolchains
 - Convenient execution of tasks in composite builds
 - Consistent dependency resolution
For more details see https://docs.gradle.org/6.8.3/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :lsifDetectJavaToolchains
BUILD SUCCESSFUL in 24s
1 actionable task: 1 executed
$ /builds/springboot-sandbox/gradlew --no-daemon --init-script /tmp/lsif-java7756353260882540485/init-script.gradle -Porg.gradle.java.installations.auto-detect=false -Porg.gradle.java.installations.auto-download=false -Porg.gradle.java.installations.paths=/tmp/lsif-java7756353260882540485/1.11 clean compileTestJava lsifJavaDependencies
To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/6.8.3/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build 
> Task :clean
> Task :compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileJava'.
> The new Java toolchain feature cannot be used at the project level in combination with source and/or target compatibility
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 5s

Why it cannot detect that this project is using java 11? I'm guessing a wrong setting in my side?

I've added in build.gradle

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}

without success

However, If I remove

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

I don't have the issue above but it is not correct as it is using java8, my project is using java-11.

[emirot]

My understanding is that the appropriate JVM version will be installed thanks to coursier?
From https://github.com/sourcegraph/lsif-java/blob/main/bin/lsif-java-docker-script.sh

[emirot]

@olafurpg this is something I would love to add to the doc.

[olafurpg]

@emirot Thank you for reporting! I opened a PR https://github.com/sourcegraph/lsif-java/pull/381 documenting how to change the default Java version in the Docker container.

You can change the java version with eval "$(coursier java --jvm 11 --env)", for example

❯ docker run -it -v $(pwd):/home/gradle sourcegraph/lsif-java:latest /bin/bash
root@ab75d18a44b4:/home/gradle# java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_312-b07)
OpenJDK 64-Bit Server VM (Temurin)(build 25.312-b07, mixed mode)
root@ab75d18a44b4:/home/gradle# eval "$(coursier java --jvm 11 --env)"
java -version
root@ab75d18a44b4:/home/gradle# java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)

Alternatively, you can create a lsif-java.json file at the root of your git directory with the following value

// lsif-java.json
{
  "jvm": "11"
}

The lsif-java command in the docker container respects that JSON config.

[k24dizzle]

I've tried running eval "$(coursier java --jvm 11 --env)" and it does seem like it changes the java -version. However, running lsif-java index still mentions that it uses Using JVM version '8'. Am I missing a step somewhere?

...
15:34:08  + java -version
15:34:08  openjdk version "1.8.0_312"
15:34:08  OpenJDK Runtime Environment (Temurin)(build 1.8.0_312-b07)
15:34:08  OpenJDK 64-Bit Server VM (Temurin)(build 25.312-b07, mixed mode)
15:34:08  ++ coursier java --jvm 11 --env
15:34:10  + eval 'export CS_FORMER_JAVA_HOME="$JAVA_HOME"
15:34:10  export JAVA_HOME="/root/.cache/coursier/jvm/[email protected]"
15:34:10  export PATH="/root/.cache/coursier/jvm/[email protected]/bin:$PATH"'
15:34:10  ++ export CS_FORMER_JAVA_HOME=/opt/java/openjdk
15:34:10  ++ CS_FORMER_JAVA_HOME=/opt/java/openjdk
15:34:10  ++ export JAVA_HOME=/root/.cache/coursier/jvm/[email protected]
15:34:10  ++ JAVA_HOME=/root/.cache/coursier/jvm/[email protected]
15:34:10  ++ export PATH=/root/.cache/coursier/jvm/[email protected]/bin:/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15:34:10  ++ PATH=/root/.cache/coursier/jvm/[email protected]/bin:/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
15:34:10  + java -version
15:34:10  openjdk version "11.0.11" 2021-04-20
15:34:10  OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
15:34:10  OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
15:34:10  + lsif-java index
15:34:10  Using JVM version '8'
...

[emirot]

if you are inside a docker image it will be overwritten by https://github.com/sourcegraph/lsif-java/blob/main/bin/lsif-java-docker-script.sh

What worked for me

build:code_intel:
  stage: hook
  image: sourcegraph/lsif-java:0.7.2
  allow_failure: true # recommended
  script:
    - echo "{\"jvm\":\"11\"}" > lsif-java.json
    - lsif-java index --build-tool "Gradle"
    - ls -lah /builds/mygroup/springboot-sandbox/dump.lsif
  artifacts:
    reports:
      lsif: /builds/mygroup/springboot-sandbox/dump.lsif
  tags:
    - build

$ lsif-java index --build-tool "Gradle"
Using JVM version '11'

but well then it doesn't see it in gitlab ui, not sure why, but the dump.lsif file is created

[olafurpg]

My bad, using eval .. won't work because the lsif-java script defaults to Java 8 anyways. Your workaround is OK for now. I'll see what we can do to improve this situation.