Closed turing85 closed 3 years ago
/cc @Sanne, @gsmet
@Sanne looks like hibernate generates proxies with the version of the VM that runs augment, with no way to change it (it would need to be an additional ctor param to BytecodeProviderImpl which would need to pass it into ByteBuddyState).
thanks for the analysis @stuartwdouglas and @turing85 !
But general question first. Should we really support the case of people running an older JDK at runtime than the one used during our augmentation phase?
We can certainly improve things, but I wonder what kind of rabbit hole this brings us into. Perhaps a global upfront check at framework level would be a better direction?
@Sanne scenario, in which I ran into the problem:
mitable-jar
on my machine, build a docker image, deploy it thorough docker-compose
(I specifically avoid building from within a container through, e.g., a multistage-docker file since we cannot mount anything at image buildtime and thus caching dependencies is a struggle)remote-dev
session to the docker deploymentI certainly agree that, when built through a pipeline, the java-version building the artifact should match the java-version running the artifact. But for local development, it should be possible to use a more recent java-release. Furthermore, we have a dedicated compiler-flag (--release
) to fixate the java-version we target, so why not use it?
@turing85 yes I agree, all good points and we can certainly improve things in the Hibernate extensions.
I'm just concerned that this won't be the last of such issues even if we solve it - we might need a more comprehensive approach.
@stuartwdouglas what about MR jars (for example?): will we need to ensure the classloaders load the right class for the target deployment version (which is apparently not the same thing as the version used at augmentation)
@Sanne while there are issues around this, IMHO I think this one is easy to fix. As I understand it the proxies in question won't be using any class file features introduced after JDK8, so it is easiest just to hard code the generated class format to JDK8.
We have seen other similar errors, and we recommend that you build and deploy with the same JDK, but as much as possible we have been fixing these on a 'best effort' basis when they crop up.
pushed this to Hibernate ORM:
Will be included in upcoming 5.4.27.Final
release - then we need to follow up with some Quarkus patch which sets the expected build version.
Describe the bug We can set the java release version to be used through maven property
maven.compiler.release
(e.g.<maven.compiler.release>11</maven.compiler.release>
)When the project is then compiled with a
javac
version >= 11 and run with java 11, anjava.lang.UnsupportedClassVersionError
is thrown on application startup.Expected behavior All sources should be compiled to target the specified java release, and the application should start up.
Actual behavior On application startup, the following exception is thrown:
To Reproduce
https://github.com/turing85/quarkus-hibernate-javaversion-bug
verify
javac
version is>11
:Compile project, start docker-container:
./mvnw clean install -Dquarkus.container-image.build=true && docker run quarkus-bug/hello-app:1.0.0
Environment (please complete the following information):
Output of
uname -a
orver
:Linux XXX 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -version
:openjdk 14.0.2 2020-07-14 OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.2+12) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.2+12, mixed mode, sharing)
GraalVM version (if different from Java): N/A
Quarkus version or git rev:
1.10.3.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
):Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /home/marco/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3 Java version: 14.0.2, vendor: AdoptOpenJDK, runtime: /opt/adoptOpenJDK/14.0.2+12 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.4.0-58-generic", arch: "amd64", family: "unix"
Additional Information: The problem starts occurring if and only if
quarkus.datasource.db-kind
is set.