Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UnsupportedClassVersionError: AndroidLocationsProvider (class file version 55.0) #378

Open
TWiStErRob opened this issue Jan 25, 2023 · 5 comments

Comments

@TWiStErRob
Copy link

TWiStErRob commented Jan 25, 2023

Hi, I started sporadically getting this error yesteday:

Run android-actions/setup-android@v2
  env:
    JOB_NAME: AGP 3.5.x on Gradle 6.x (3.5.4) on 6.7.1)
    GRADLE_VERSION: 0.0.0
    JAVA8_HOME: /usr/lib/jvm/temurin-8-jdk-amd64
    JAVA11_HOME: /usr/lib/jvm/temurin-11-jdk-amd64
    JAVA_HOME: /usr/lib/jvm/temurin-8-jdk-amd64
/usr/local/lib/android/sdk/cmdline-tools/latest/bin/sdkmanager cmdline-tools;7.0
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/android/prefs/AndroidLocationsProvider has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
	at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
	at java.lang.Class.getMethod0(Class.java:3018)
	at java.lang.Class.getMethod(Class.java:1784)
	at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:650)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:632)
/home/runner/work/_actions/android-actions/setup-android/v2/dist/index.js:2348
                error = new Error(`The process '${this.toolPath}' failed with exit code ${this.processExitCode}`);
                        ^

Error: The process '/usr/local/lib/android/sdk/cmdline-tools/latest/bin/sdkmanager' failed with exit code 1
    at ExecState._setResult (/home/runner/work/_actions/android-actions/setup-android/v2/dist/index.js:2348:25)
    at ExecState.CheckComplete (/home/runner/work/_actions/android-actions/setup-android/v2/dist/index.js:2331:18)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/android-actions/setup-android/v2/dist/index.js:2225:27)
    at ChildProcess.emit (node:events:527:28)
    at maybeClose (node:internal/child_process:1092:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)

It happens randomly. I have a big matrix 38 jobs, 23 of them use Java 8, and 2-3 of them randomly chosen of the 23 fail with the above.

My guess is that cmdline-tools:latest was just released with a requirement on Java 11. And this setup-android action is just showing the problem, not causing it. Reported here anyway just in case you know anything, and others are looking at the same problem.

Example fail: https://github.com/TWiStErRob/net.twisterrob.gradle/actions/runs/3939418181/jobs/6862851517
(Note that it is Attempt 2, because the original Attempt 1 execution didn't fail, and because it's on master nothing has changed since Attempt 1 in my code.)

The only other reference to this I found: https://ask.csdn.net/questions/7878632

@S64
Copy link

S64 commented Jan 26, 2023

Same issue here.

trace
Run android-actions/setup-android@v2
  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Adopt_jdk/8.0.362-9/x64
    JAVA_HOME_8_X64: /opt/hostedtoolcache/Java_Adopt_jdk/8.0.362-9/x64
    MSYS: winsymlinks:nativestrict
/usr/local/lib/android/sdk/cmdline-tools/latest/bin/sdkmanager cmdline-tools;7.0
Error: A JNI error has occurred, please check your installation and try again
Error: Exception in thread "main" java.lang.UnsupportedClassVersionError: com/android/prefs/AndroidLocationsProvider has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:3[69](https://github.com/****/****/actions/runs/****/jobs/****#step:3:73))
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2[70](https://github.com/****/****/actions/runs/****/jobs/****#step:3:74)1)
	at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
	at java.lang.Class.getMethod0(Class.java:3018)
	at java.lang.Class.getMethod(Class.java:1784)
	at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:650)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:632)
/home/runner/work/_actions/android-actions/setup-android/v2/dist/index.js:2348
                error = new Error(`The process '${this.toolPath}' failed with exit code ${this.processExitCode}`);
                        ^

Error: The process '/usr/local/lib/android/sdk/cmdline-tools/latest/bin/sdkmanager' failed with exit code 1
    at ExecState._setResult (/home/runner/work/_actions/android-actions/setup-android/v2/dist/index.js:2348:25)
    at ExecState.CheckComplete (/home/runner/work/_actions/android-actions/setup-android/v2/dist/index.js:2331:18)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/android-actions/setup-android/v2/dist/index.js:2225:27)
    at ChildProcess.emit (node:events:527:28)
    at maybeClose (node:internal/child_process:10[92](https://github.com/****/****/actions/runs/****/jobs/****#step:3:97):16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)

Fortunately, my project had already migrated from JDK8 to JDK11, and simply removing the JDK8 reference from workflow solved the issue.

Here is an example of the change in my project.
I can only show you an excerpt, but you can see that I changed to set up JDK11 before calling actions/setup-android@2.

diff --git a/.github/actions/setup/action.yml b/.github/actions/setup/action.yml
index 403b46913..f5fd01c1f 100644
--- a/.github/actions/setup/action.yml
+++ b/.github/actions/setup/action.yml
@@ -8,7 +8,7 @@ runs:
     - uses: actions/setup-java@v3
       with:
         distribution: 'adopt'
-        java-version: '8'
+        java-version: '11'
     - uses: actions/cache@v3
       with:
         path: |
@@ -18,9 +18,5 @@ runs:
         key: ${{ inputs.cache_key }}
     - name: Setup Android SDK
       uses: android-actions/setup-android@v2
-    - uses: actions/setup-java@v3
-      with:
-        distribution: 'adopt'
-        java-version: '11'
     - run: make publish-local
       shell: bash

@TWiStErRob
Copy link
Author

Yeah, I started upgrading my project from Java 8 to Java 19 too (not results yet, in progress), it should hide this problem. The weirdest thing is it being random.

Also follow https://issuetracker.google.com/issues/266618722 in case they update the docs and confirm my suspicion.

@ViliusSutkus89
Copy link
Collaborator

Sorry mates, took me a while.

I have no idea why it was sporadic, but this is JDK version issue. I am not sure about cmdline-tools 10.0, but current version 11.0 requires JDK 17.

setup-android action runs sdkmanager (part of cmdline-tools) as part of it's install process, this means that the action requires the same JDK version that is required by the cmdline-tools.

@TWiStErRob , @S64 , is it reasonable for me to expect y'all to just upgrade to JDK17 (or later) or is it necessary for us to make something work with JDK11?

@TWiStErRob
Copy link
Author

Since AGP 8 requires JDK 17 too, this requirement is more relaxed from your side, unless projects use AGP pre-8 + latest Android SDK. This should cover "normal" use cases.

This pattern might help to run Gradle and Android SDK on latest JDK, but keep testing lower versions.

However, I for example have a Gradle plugin where I test compatibility and run older AGP/Gradle GitHub actions matrix where I need to use Java 11 (because old AGP/Gradle CANNOT run on Java 17). To work around this I use essentially following order: setup-java=17, setup-android, setup-java=${{ matrix.java }}, gradlew .... This works because I make sure to pre-install everything so there's no sdkmanager calls during build.

Is it possible to specify a Java version internally akin to?

using: node20

This would allow setup-android to use the right version, and the outer world could have whatever they desire or nothing at all.

@TWiStErRob
Copy link
Author

Is it possible to specify a Java version internally akin to?

Few thousand lines of yaml later...

It would be possible to set up your own Java if this was implemented:
actions/setup-java#552

However the action would need to be wrapped in a using: composite.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants