How important is the minor version of the Java Build SDK vs. the JDK version at runtime, is it a problem if the minor version is a bit outdated, if the run time version is still up to date?

More details:

We are using Java 17 to build an application, but it is an outdated Version of OpenJDK, i.e. 17 GA (build 17+35). There is already a newer Version out of OpenJDK, i.e. 17.0.2, but OpenJDK has classified this version as "superseded" and recommends to use an altogether newer major JDK version, i.e. 17+. But we want to stay with the major Java 17 version, because we don't want to refactor application for now. And there are other vendors who provide JDK's with the major version 17 that are still supported.

Our Application actually runs in the Azure cloud on App Service with an out of the box Java Runtime, I think it is based on Eclipse Temurin 17, which still has a "supported" version of Java 17, right now 17 jdk-17.0.9+9.1. Does it even matter if we upgrade our local Java SDK in the build server to a supported Java 17 version, or can we just leave it as is, since the runtime is an up to date Java 17 that is supported?

I mean there also libraries built on older minor versions, do they ever get rebuild on a newer minor JDK version if there is a release? I suppose not, so likewise it wouldn't make sense to update our build SDK if we want to stay with Java 17.

Is that correct?

  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    Commented Dec 9, 2023 at 1:55

1 Answer 1


There are advantages to rebuilding on the new SDK, but none of the advantages are security advantages.

Java compiles to ByteCode. Each JVM is certified to use and react to the ByteCode in the same way, so it rarely matters if the JVM version matches the compiler version.

What does matter is that the libraries and classes are available, and the JVM provides core libraries. If you compile on a newer version of Java and then run on an older version of the JVM, you need to ensure that your compilation on the newer version of Java doesn't use libraries that are not within the core of an older JVM.

Occasionally JVMs have bugs in them (or in the core libraries they offer). The main reason to upgrade JVMs is to avoid these bugs, and thus it is often more important to upgrade the JVM the program runs on than the JVM the program was compiled with.

For third-party libraries (libraries not within the JVM core, or not within the code you wrote), keeping those libraries up to date is often more important than the JVM you select, as more security issues are introduced through third-party libraries than through JVM or JVM provided core libraries.

  • Can't incorrect bytecode lead to security issue?
    – Basilevs
    Commented Dec 10, 2023 at 20:19
  • @Basilevs It can, but changing the JVM or the Java Compiler can't put security issues into Java Bytecode. The thing that changes the possible security issues that might be found in Java Bytecode is the source code being compiled. That source code is mostly written by the programmer that is writing the application, not by the team that is writing the JVM. Remember the JVM only does what the Program it is running tells it to do. It's not like a JVM will start running random stuff unless the programmer of the program is ignoring good programming practices.
    – Edwin Buck
    Commented Dec 10, 2023 at 20:39
  • Compiler is the only thing that writes bytecode and yet, source code is to blame for all bugs in bytecode? I say, both contribute to security concerns.
    – Basilevs
    Commented Dec 11, 2023 at 16:57
  • @Basilevs The bytecode is roughly an exact translation of the source code. There's no code within a class file that isn't directly controlled or determined by the source code. The compiler in Java does a lot less work than compilers do in other systems. Since I reverse engineer Java code occasionally, you can either take my word for it, or you can learn how to reverse engineer bytecode yourself.
    – Edwin Buck
    Commented Dec 11, 2023 at 22:29
  • are you saying that compiler bug producing invalid bytecode is unlikely? We know for a fact that compilers have bugs and producing bytecode is one of their most important roles, hence my confusion.
    – Basilevs
    Commented Dec 12, 2023 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.