Hi Tony, Thanks for the links! The API looks very promising. Out of curiosity, why aren't you using the Base64 MIME encoder/decoder? They are supposed to produce/remove the newline characters. The relationship between the byte[] and String data should be specified. Base64 explicitly specifies that the String APIs are translated to the byte[] APIs with ISO 8859-1 encoding. The PEMDecoder is currently using the default charset, which might produce interesting results if the charset is set to EBCDIC. The encoder is using UTF-8, which is reasonable, but given that the produced output will always be ASCII, ISO 8859-1 will perform better. There's a disparity between the decoder and the encoder APIs; both work with strings, but Decoder accepts InputStream and not arrays, and Encoder produces byte arrays, but does not work with streams. This should be more uniform. I like Decoder's InputStream support (that's currently the only way to read multiple CA certificates from a single file - the String overload currently only returns the first one), so I'd add OutputStream support to Encoder for parity. Karl's earlier suggestion to support Stream<SecurityObject> also makes a lot of sense. I'm not a big fan of the non-static factory methods withEncryption/withDecryption/withFactory. The problem with non-static methods that return an instance of the same type is that you need to check the documentation to know if the method returns a new instance or if it mutates the current one. Can we use static factory methods instead? Either that, or create a builder class. I don't like the PEMEncoder.withEncryption API. It's not predictable enough; when encoding data, it's not consistent between writing unencrypted data (certificate, crl), throwing (PublicKey, EncryptedPrivateKeyInfo) and writing encrypted data (unencrypted private keys). The alternative of forcing the users to encrypt using EncryptedPrivateKeyInfo looks better to me. I'd love to see support for the OpenSSL private key formats; it seems that RSAPrivateCrtKeyImpl already supports PKCS#1 format, so it may be just a matter of exposing that functionality. Other key types like EC might need more work. That might be added later after the API is finalized.
Thanks, Daniel śr., 24 sty 2024 o 22:24 Anthony Scarpino <anthony.scarp...@oracle.com> napisał(a): > > Hi, > > The following github link is to the PEM API as it is written in the > draft JEP (https://openjdk.org/jeps/8300911). There has been a few > changes since the original posting. > > https://github.com/ascarpino/jdk/tree/pem > > The Encoder and PEMEncoder to now return byte[] for the encode() method. > A new PEMEncoder method, encodeToString(), was added. I believe these > make it easier for outputting data to a file and InputStreams, while > still supporting a method that returns a String. > > For decode, InputStream has replaced Reader. There were comments > preferring InputStream and I found that Reader's buffering quirks were > problematic. Decoding from a byte[] is easy through an ByteArrayInputStream. > > If you are interested in testing out the API, please download and > compile the repo. Then let me know how your experience went. > > thanks > > Tony
