Skip to content

Conversation

@adoroszlai
Copy link
Contributor

@adoroszlai adoroszlai commented Jan 16, 2026

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

@adoroszlai adoroszlai self-assigned this Jan 16, 2026
@adoroszlai adoroszlai added the build Pull request that modifies the build process label Jan 16, 2026
@ivandika3 ivandika3 requested a review from symious January 17, 2026 02:12
@ivanzlenko
Copy link
Contributor

Thanks for the patch!

@errose28
Copy link
Contributor

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Pull request that modifies the build process

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants