Interface BinaryEncodable

All Known Subinterfaces:
AsymmetricKey, DHPrivateKey, DHPublicKey, DSAPrivateKey, DSAPublicKey, ECPrivateKey, ECPublicKey, EdECPrivateKey, EdECPublicKey, PrivateKey, PublicKey, RSAMultiPrimePrivateCrtKey, RSAPrivateCrtKey, RSAPrivateKey, RSAPublicKey, XECPrivateKey, XECPublicKey
All Known Implementing Classes:
EncryptedPrivateKeyInfo, KeyPair, PEMPREVIEW, PKCS8EncodedKeySpec, X509Certificate, X509CRL, X509EncodedKeySpec
public sealed interface BinaryEncodable permits AsymmetricKey, KeyPair, PKCS8EncodedKeySpec, X509EncodedKeySpec, EncryptedPrivateKeyInfo, X509Certificate, X509CRL, PEMPREVIEW (not exhaustive)
BinaryEncodable is a preview API of the Java platform.
Programs can only use BinaryEncodable when preview features are enabled.
Preview features may be removed in a future release, or upgraded to permanent features of the Java platform.
This interface identifies the cryptographic objects that can be converted to and from binary data, and thereby encoded and decoded as PEM text.

The APIs for cryptographic objects such as public keys, private keys, certificates, and certificate revocation lists all provide the means to convert their instances to and from standardized binary representations. Other kinds of cryptographic objects, such as certificate requests, have no corresponding API but can still be expressed as standardized binary representations. The BinaryEncodable interface allows the PEMEncoderPREVIEW and PEMDecoderPREVIEW classes to operate uniformly on binary representations of key or certificate material.

The permitted subtype PEM is notable for supporting the encoding and decoding of PEM text that represents cryptographic objects for which no API exists. In future releases, other permitted subtypes may be added to support the encoding and decoding of such cryptographic objects.

The list of permitted subtypes shown after permits is not exhaustive. This means if application code switches over a BinaryEncodable value, the switch cannot be made exhaustive simply by providing a case label for every permitted subtype shown in the list; there also must be a default or case BinaryEncodable label to handle additional subtypes. This allows the list of permitted subtypes to change over time without causing pre-existing switches to fail because of an unrecognized subtype.

Since:
27
See Also: