Clojurians Log v2

Hi! This morning, besides CLJ-Kondo also VSCode was updated. Now I’m getting this error:

Exception in thread "main" java.lang.UnsupportedClassVersionError: clj_kondo/lsp_server/main : Unsupported major.minor version 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:808)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:443)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:65)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:349)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:348)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:430)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:329)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:363)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:588)
[Info  - 9:42:46 AM] Connection to server got closed. Server will restart.

hmm, this might be due to me accidentally using Java 11 for deployment? But then I would have expected version 55.0 not being supported, since 52.0 is the old one

Are you using Java 1.7 or something on your system?

^ @stefan.van.den.oord

@borkdude I’m using java 8 for this (but I also have java 7 around)

Java SE 8 = 52
Java SE 7 = 51

I’m using asdf-vm so “that should not be possible” 😉 But your reasoning is correct. I’ll see if I can find out what vscode is using. But does your release explain that this now happens for the first time then?

Could happen when the Java compiler emits bytecode that's only supported by Java 8 possibly? And it didn't before because it wasn't necessary? Dunno. Maybe you can type java -version in a vscode terminal

openjdk version “1.8.0_265” OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_265-b01) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.265-b01, mixed mode)

There could also be that Calva’s jackInEnv setting is in play, @stefan.van.den.oord.

$ file ./clj_kondo/core__init.class
./clj_kondo/core__init.class: compiled Java class data, version 52.0 (Java 1.8)

seems ok

@pez Just defaults there…

I don't have any other explanation than that Java 7 or older is invoked. Maybe remove it from your system and try again.

I can try indeed. It won’t be a solution though because java7 is required for the product I’m developing on. 😞

Either that or fix the path issue that is causing java7 to take precedence. Or make a PR that runs the clj-kondo server in a docker container ;) (Don't know if that's a good idea or not)

I first need to understand why this broke. Java 7 is not on my path normally, thanks to asdf-vm. Tuesday it still worked.

You could try to test if the older version of clj-kondo from the marketplace does work for you.

Already did, same problem 😞 It does seem to be a local issue on my machine.

Removing java 7 fixes it, so definitely local issue.

Oh wow that was an interesting corner case. Using asdf-vm the required versions of all tools can be set on a per-directory basis. The global default is java 8, and in that one project I locally set it to java 7. When I open a terminal, it will use the default and all is fine. In this specific case, I happened to have shut down my mac with an open terminal window in that specific folder. After rebooting, the apps got automatically relaunched, and iTerm happily created the terminal in that folder again, causing it to default to Java 7. Pff. Anyway, solved. Thanks!