HDDS-14439. Require Java 17 for server components

[adoroszlai]

What changes were proposed in this pull request?

• Require Java 17 for building and running Ozone server components, including admin tools.
• Keep supporting Java 8 for client components.
• Disable findbugs check (temporarily) because Spotbugs 3 does not work with Java 17, and Spotbugs 4 reports 2K+ new warnings. Project to fix Spotbugs violations: HDDS-10150.

Discussion: https://lists.apache.org/thread/k9kvobrg7ybthjfs78rfscpc2lty5x5y

https://issues.apache.org/jira/browse/HDDS-14439

How was this patch tested?

CI:
https://github.com/adoroszlai/ozone/actions/runs/21066105001

[ivanzlenko]

Thanks for the patch!

[errose28]

Thanks for working on this @adoroszlai. Can we fully switch to using maven.compiler.release instead of javac.version as described in HDDS-13670 as part of this PR? Here we are adding another java version field without removing the old one that was already redundant.

Also should the default build behavior for the client be to inherit the version from the JDK being used, or should it default to 8 and require passing maven.compiler.release if a different bytecode version is required? I think since we are setting a server side default we should probably explicitly set a client side default as well for consistency.

[adoroszlai]

Can we fully switch to using maven.compiler.release instead of javac.version as described in HDDS-13670

Created separate PR #9693.

Also should the default build behavior for the client be to inherit the version from the JDK being used,

That wouldn't work: to get client jars for JDK 8, we'd need to build with JDK 8, but server-side part requires JDK >= 17.

we should probably explicitly set a client side default as well for consistency

Now we have two sets of modules, "server" (explicitly have maven.compiler.release set) and "other" (inherits from root POM). If we did have maven.compiler.release in all modules (server or client), consider the case where a new module is being added but the author forgets to set the property.

[szetszwo]

@adoroszlai , thanks for working on this!

Since we are specifying the min, JDK 17 is more restrictive than JDK 8. For inheritance, the subs should be more restrictive than the base. So, how about setting the default JDK version to 17 in the base and setting the client modules explicitly to 8?

[szetszwo]

If we remove the JDK 8 and 11 cases, someone could break JDK 8 compatibility without be notice (e.g. using JDK 9 syntax in the code or adding a new client module requiring JDK 17). Is it possible to run test using JDK 17 to start the servers and JDK 8 to run the clients?

Or we should add a new test matrix to use JDK 8 compiling all the client modules and run some tests not requiring the servers (e.g. print out the version).