Refactor PlatformDependent0 using multi-release JAR to eliminate reflective version checks
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 35.1k
- Forks
- 16.3k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 143
Description
Now that #14267 has been merged and Netty JARs are multi-release to include module-info.class, I'd like to propose taking the next step: refactoring PlatformDependent0 in netty-common to actively use the META-INF/versions/ mechanism.
Currently, PlatformDependent0 relies heavily on reflection hacks to handle differences between Java versions (e.g., Unsafe, VarHandle, MethodHandles). This approach is fragile, slower, and hard to maintain due to many if (isJavaXX()) branches and try-catch blocks.
With a multi‑release JAR, the JVM automatically selects the appropriate class version at runtime based on the current Java version. If no exact match is found, it falls back to the base implementation (Java 8). This eliminates the need for manual version checks.
The goal of this ticket is not to write new logic, but to reorganize the existing code. The current PlatformDependent0 already contains conditional logic for different Java versions — this would be split into two versions:
- Base version (Java 8) — the current code, placed in the JAR root.
- Versioned implementation (Java 25+) — a copy with all conditional checks removed, placed in
META-INF/versions/25/(in the JAR; source roots likesrc/main/java25are typical during development).
Proposed scope
- Only
netty-commonmodule, specificallyPlatformDependent0. - Target versions:
- Java 8 — base implementation.
- Java 25+ — optimized version using
VarHandleandMethodHandleswithout reflection (Java 25 is the latest LTS).
- No changes to public API — internal refactoring.
Benefits
- Cleaner, more maintainable code.
- Better runtime performance (direct handles vs. reflection).
- Future‑proofing for newer Java features.
- Demonstrates the pattern for other Netty modules.
Non‑goals
- Extending to other modules (
netty-buffer,netty-transport, etc.). - Changing native code / JNI.
- Dropping support for Java 8.
Additional note:
I plan to start working on this in the coming days. If there are any concerns or feedback, please let me know.
/cc @vietj @chrisvest @normanmaurer — this was briefly discussed in https://github.com/netty/netty/pull/14267#issuecomment-2316233529.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading netty-common's PlatformDependent0 and the existing multi-release JAR setup introduced by #14267. Compare the Java 8 base implementation with the proposed Java 25+ source under a versioned source root such as src/main/java25. Done means the JAR contains both implementations, Java 8 remains supported, and the versioned implementation removes the described reflective version checks without public API changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, build-system
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100