[New API] Proposal to Export Selected Internal APIs from java.base to Reduce Duplication
OblivRuinDev
2021777011 at qq.com
Sat Aug 2 12:43:13 UTC 2025
As a long-time Java developer, I’ve observed that some internal APIs within java.base provide functionality needed by third-party libraries. However, since these APIs are not exported, libraries only reimplement similar logic, leading to redundant bytecode and increased class-loading overhead. This duplication impacts runtime efficiency and maintenance.
I propose exporting some non-sensitive APIs from java.base to a public package, provided they:
Preserve JDK integrity/security (e.g., avoid exposing critical internals).
Some methods annotated with @IntrinsicCandidate
Some APIs I consider it is non-sensitive and exports-valuable:
class: java.lang.StringCoding
method: java.lang.StringLatin1.inflate(byte[], int, char[], int, int)
Expected Benefits:
Reduce bytecode duplication → Smaller footprint and fewer loaded classes.
Leverage JDK intrinsics → Better runtime performance.
Simplify library code
Some API could moved to a new package(e.g. java.misc) to export to thrid-party libiaries, and we could consider move some new APIs to this package in the next step of development.
Feel sorry about my bad English
Thank you for considering this proposal!
Best regards,
OblivRuinDev
2025.08.02.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250802/76e0dffc/attachment.htm>
More information about the amber-dev
mailing list