I’m working on providing jdbc support to dbquery addon, and today I’m not able to build the add-on due to the following error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile (default-testCompile) on project org.openhab.binding.dbquery: Execution default-testCompile of goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile failed: Unsupported major.minor version 56.0 -> [Help 1]
As the error didn’t give any information I used the -e option and put a breakpoint where it is launched.
And I’ve seen that the problem is launched from the indriya dependency that has some classes for JAva 12 and 14.
That dependency is not used directly by the addon but it’s inherited from the openhab-addons bom.
Has anyone had that error and can give some clue of how to manage it?
The failing code is in this branch if someone wants to test:
For me, it’s reproducible by just doing
I’ve found that the problem is solved if I use an older version of caffeine.
But there’s something strange here, which escapes my knowledge. Because caffeine 3 should work with Java 11, and I have no idea because the error is reported by indriya dependency
I believe issue comes from fact that you try to compile using JDK 1.8 things which use Java 11 quirks. Switch your build JDK to 11 and it should be fine.
The Java 14 stuff in indriya shouldn’t worry you much since Java supports multi release JARs. The Java 14 specific parts will be omitted by classloaders if you run on 11.
The other error you observe is related to dependency management. Make sure you have one version of indriya on classpath. Maven
dependency:tree goal is your friend there.
Thanks Lukasz, but no, I don’t know exactly where the problem is but it’s not using the wrong JDK.
I think that it must be something with the maven bnd plugin, because it has some issues like this workaround that I’ve to apply.
And about the dependency management the indriya dependency it’s only used by the openhab bom compile dependency, and I can’t do anything about it.
The problem must be in some multirelease problem introduced by caffeine but I don’t have time to analyze in more detail, and using an older version it’s good enough for my addon use case.
All right, since I don’t use openHAB bom in my addons I haven’t found this issue. Now after looking at what you linked I see there is an area where bnd could get lost. Yet its not something which would break your build.
Looking once again at your error message you can read following:
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:
testCompile. You have failure before bnd could jump in.
By following Class File Versions - javaalmanac.io you can find that “Unsupported major.minor version 56.0” indicates a bytecode version used in Java 12. Hence Java 11 is not sufficient to compile it. Clearly one of your dependencies, maybe indriya, was compiled exclusively against this version. However if your test compile was affected, look first at test dependencies.
I’m facing the exact same problem. You can reproduce it with any binding, just add this dependency:
version does not even matter. The “funny” thing is the error shows up ONLY in mvn test. mvn compile runs absolutely fine. That stuff should be fixed within the openHAB bom.
@touitoui you found guilty dependency then.
I am not sure if OH BOM force specific versions (or it just promotes specific dependencies). You can try to add local
dependencyManagement section in your binding pom and rule older version of this dependency to avoid compilation crash.
I am not quite sure why it happens with test-compile. With dependency declaration you showed it should cause an intermediate failure at first compile attempt.
@splatch OH BOM does not specify this dependency as far as I’ve seen. The fact that this dep makes no problem whatsoever when you just compile prod code makes the mvn test phase at least suspicious I’ll workaround the problem for now as I don’t have the time to debug OH BOM.
Just tested jSerialComm with mvn test in a project without OH BOM as parent. Same java, same mvn, same machine - works like a charm.
Hi @touitoui, what workaround have you used?
@lujop Certainly not the most pleasant one: I isolated the critical part of my binding from openhab libs and tested it within a fresh mvn project. After all my tests are green I just copy/paste it back into openhab repo and wait til someone upstream fixes the root cause of the issue. After that, I will copy/paste my tests too.
Regarding root cause solution: The jSerialComm dep which caused the symptom for me defines a jigsaw module descriptor (module-info.class). Maybe you can check if that’s also the case for your dep culprit. But that’s just a quick guess.
Yes, it’s exactly the same case. The Caffeine library for version 3.0 has a module descriptor.