A proposal aims to enforce strong encapsulation in Java APIs to protect code integrity, while another introduces a Key Encapsulation Mechanism (KEM) API for enhanced encryption.
Two key proposals circulating in the open-source Java community aim to strengthen both code integrity and encryption in the Java platform. One proposal focuses on enforcing stronger encapsulation of Java APIs, while another introduces an API for Key Encapsulation Mechanism (KEM), designed to safeguard encryption in the era of quantum computing.
The proposal for tighter encapsulation is outlined in a draft Java Enhancement Proposal (JEP) on openjdk.org. It intends to restrict APIs from breaking Java’s strong encapsulation, a core feature that ensures the integrity of code and data. While strong encapsulation provides default protection for Java applications, certain APIs can bypass these boundaries, creating potential issues with performance and security.
Incorporating this proposal into the standard edition of Java would involve several key goals. First, it aims to preserve Java’s invariants—conditions that must always hold during operation. This is essential for maintaining the security, performance, and overall maintainability of Java systems. The proposal also seeks to clearly define which Java and non-Java APIs should or should not be allowed to breach encapsulation.
Another goal is to differentiate cases where breaking encapsulation might be convenient, such as for performance optimizations, from situations where encapsulation must be disabled for essential operations. By doing this, Java can balance flexibility with security.
However, the JEP makes it clear that its scope is limited to safeguarding against API-based breaches of encapsulation. It is not intended to protect against users manually compromising the system at the file system, operating system, or hardware level. In such cases, appropriate operating system integrity mechanisms must be relied upon to protect Java applications.