Quarkus: Super-types of bean resolved at compile-time but not present at run-time cause start-up failure

[plevart]

One example of the problem is described in issue #5062 which has been fixed with a work-around for that particular bean type (String) and its super-types. This issue is about investigation and proposals to find a more general fix for the problem.

[dmlloyd]

During the build, we may do any or all of the following:

1. Reflectively examine and/or index classes on the class path for structure
2. Reflectively analyze the method bodies of classes on the class path and their dependencies
3. Execute some code on the class path
4. Store information dependent on any of the above

Because of this, differences in the JDK at build and run time have a much greater impact than what can be solved by usage --release 8, which (within the scope of javac) uses a stubbed version of JDK 8 instead of the normal run time JDK of the compilation environment.

Here are the possible solutions that I can think of:

1. Never introspect private/package-private members of the JDK in any way for any reason
2. Require that the application run on the same JDK (not just major version, but the exact same JDK) for which it was built or face undefined/unpredictable behavior

[dmlloyd]

Note that this will (at least in theory) affect building on Mac/Windows and deploying to Linux/etc.

[maxandersen]

Just to clarify - this is not specific to native image this a plain Quarkus JVM built jar that won't necessarily run on different major/minor versions of Java and in worst case not on the same JDK version because the jdk class library can be different between Operating systems ?

[dmlloyd]

Just to clarify - this is not specific to native image this a plain Quarkus JVM built jar that won't necessarily run on different major/minor versions of Java and in worst case not on the same JDK version because the jdk class library can be different between Operating systems ?

Correct, this applies to JVM mode. Native images don't actually have this problem because in a sense, they carry the JDK inside of them.

[maxandersen]

So in theory this could even be an issue if you build your app on a linux box based on ubunutu but in production runs on centos/rhel based openjdk ?

[dmlloyd]

So in theory this could even be an issue if you build your app on a linux box based on ubunutu but in production runs on centos/rhel based openjdk ?

I think that is unlikely if the JDK is identical between them (because the class structure and API implementations of the JDK will not differ in this case).

[stuartwdouglas]

The linked issue is not about package private members of the JDK, the issue is that additional interfaces have been added to java.lang.String and other constant types. These will be present no matter the minor version.

We should not be introspecting implementation details of the JDK unless the users code is using it directly in their application.

I don't think this will be a big problem outside of this particular case. There is only a small set of JDK types that are regularly used as CDI beans, and adding additional interfaces will likely not happen very often.

[stuartwdouglas]

I am closing this, as I don't think there is anything we can do in the general case, and as these issues are relatively rare I think all we can do is fix them on a case by case basis.