[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