I try to find a use case when it is necessary to use a special target version of the compiler javac using the target parameter.
Java is backward compatible, isn't it? So, if I compile a hello world program with version 11, it could run on a JVM with version 8, or?
The only use case I could imagine is, when you have dependencies (other jars) which are compiled in a certain version and you have to match this special version when compiling the own code.
Java is backward compatible, isn't it? So, if I compile a hello world program with version 11, it could run on a JVM with version 8
That is exactly backward. If you have a version of a Java class compiled with version 8, Java 11 is backwards compatible and can run it. The reverse is not backwards compatibility, and is the purpose of the --target command line flag. Specifically so a class compiled by the Java 11 compiler can run on Java 8. Without that, you would get an java.lang.UnsupportedClassVersionError: Unsupported major.minor version
By default, classes are compiled against the bootstrap and extension classes of the platform that javac shipped with. But javac also supports cross-compiling.
-target version
Generate class files that target a specified version of the VM. Class files will run on the specified target and on later versions, but not on earlier versions of the VM. Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also 6), and 1.7 (also 7) ... . The default for -target depends on the value of -source:
If -source is not specified, the value of -target is 1.7
If -source is 1.2, the value of -target is 1.4
If -source is 1.3, the value of -target is 1.4
If -source is 1.5, the value of -target is 1.7
If -source is 1.6, the value of -target is 1.7
For all other values of -source, the value of -target is the value of -source.
Refer javadoc for more details here.
I try to find a use case when it is necessary to use a special target version of the compiler javac using the target parameter.
A common scenario is roughly:
Using the "target" flag, it's possible for the engineers to write software using newer/later JDK versions, while still being able to run it on an older JDK (on a production system).
And "older" really doesn't need to be all that old... for example, a production system might be running in Amazon using the latest version of Corretto (which is currently 18, with all other available versions being 8, 11, and 17), and individual engineers could have JDK 19 or 20 on their machines.
The Java Language Spec discusses this topic in Chapter 13, Binary Compatibility:
This chapter specifies minimum standards for binary compatibility guaranteed by all implementations. The Java programming language guarantees compatibility when binaries of classes and interfaces are mixed that are not known to be from compatible sources, but whose sources have been modified in the compatible ways described here.
And various more specific comments in JLS 13.2, What Binary Compatibility Is and Is Not:
A change to a type is binary compatible with (equivalently, does not break binary compatibility with) pre-existing binaries if pre-existing binaries that previously linked without error will continue to link without error.
Note: I posted links specifically from JLS version 1.8 as it's relevant to versions in this question (8 and 11), but Java's treatment of binary compatibility hasn't changed in prior or subsequent versions.
