Update to Java 25 🚀

[da-Kai]

Lets update to the latest LTS version Java 25, released on 16th September 2025 (https://en.wikipedia.org/wiki/Java_version_history#Release_table).

If you happen to receive a Eclipse warning bnd has '25' while Eclipse has '21' please update your IDE settings: https://bnd.bndtools.org/chapters/910-warnings.html

We recommend using JDK 25 from the Eclipse Temurin project: https://adoptium.net/de/temurin/releases?version=25

If you need a compatible Java 25 JRE or JDK for ARM32, we are providing prebuilt Debian packages:

• https://openems.io/download/temurin-25-jdk-armhf_25.0.3+8.deb
• https://openems.io/download/temurin-25-jre-armhf_25.0.3+8.deb

[Note] these are compatible with debian jessie and newer

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Additional details and impacted files

@@              Coverage Diff              @@
##             develop    #3544      +/-   ##
=============================================
- Coverage      60.60%   60.58%   -0.02%     
  Complexity       105      105              
=============================================
  Files           3496     3496              
  Lines         153207   153262      +55     
  Branches       11691    11694       +3     
=============================================
- Hits           92837    92832       -5     
- Misses         56884    56942      +58     
- Partials        3486     3488       +2     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Sn0w3y]

HI @da-Kai 👍 please look at my Considerations:

Java 25 Compiler Warnings

After testing this update, I noticed that Java 25's compiler is significantly stricter than Java 21, generating a large number of
new warnings across the codebase (~2000+ warnings).

1. ~95% Lambda parameter warnings (false positives)

   • The value of the lambda parameter X is not used
   • These are legitimate callback patterns where parameters are intentionally unused
   • Example: BiConsumer<Value<Integer>, Value<Integer>> onChange = (a, b) -> { ... }

2. ~4% Unused local variables (mostly harmless)

   • Standard code patterns where variables are declared but not used

Option A (Recommended):

• Fix ~2000 unused lambda parameters with _ notation
• Clear, maintainable, follows Java 25 best practices
• Can be automated with search/replace patterns

Option B:

• Document known warnings and address them incrementally
• Create follow-up issue for systematic cleanup

Option C (Not Recommended):

• Suppress warnings globally
• Loses the benefit of Java 25's improved error detection

---

Related Issues:

The Medium article "https://medium.com/@maahisoft20/i-banned-java-lambdas-in-2025-after-one-production-incident-c68daaaaf135" describes a similar scenario where unclear lambda intent caused a production bug. While our warnings are false positives, marking unused parameters explicitly prevents similar confusion.

What's your preference @da-Kai @sfeilmeier? Happy to implement Option A if approved.

---

References:

• https://openjdk.org/jeps/456 (Java 21 Preview, Java 22 Final)
• https://checkstyle.sourceforge.io/checks/coding/unusedlambdaparametershouldbeunnamed.html
• https://blog.jetbrains.com/idea/2024/03/drop-the-baggage-use-_-for-unnamed-local-variables-and-patterns-in-java-22/
• https://javadzone.com/java-21-unnamed-patterns-and-variables-with-examples/

[sfeilmeier]

What's your preference da-Kai sfeilmeier? Happy to implement Option A if approved.

@Sn0w3y: I would start with merging this PR and then fix the warnings in follow-up PRs.

There is still the question open, when to merge this PR. We were thinking to merge it e.g. just after 2026.3.0 to give the community some time to adopt - and still have 2026.3.0 as a stable version with Java 21. What do you think? How long should we wait?

[clehne]

What's your preference da-Kai sfeilmeier? Happy to implement Option A if approved.

@Sn0w3y: I would start with merging this PR and then fix the warnings in follow-up PRs.

There is still the question open, when to merge this PR. We were thinking to merge it e.g. just after 2026.3.0 to give the community some time to adopt - and still have 2026.3.0 as a stable version with Java 21. What do you think? How long should we wait?

We would also prefer to wait a bit. Releasing 2026.3.0 as (the last) stable Java 21 version sounds good.