[14] RFR 8162628: Migrate cacerts keystore from JKS

[Weijun Wang]

> On Aug 22, 2019, at 10:40 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 8/14/19 10:07 AM, Weijun Wang wrote:
>> The difference will be big. I've simplified the logic into
>> 1. read bytes between first ": " and \r\n as alias
>> 2. read bytes between first \r\n after first "-" and next "-" as a cert
>> 3. goto 1
>> And I only store the cert bytes and do not create a Certificate until getCertificate() is read. I even haven't de-BASE64 them.
>> Time spent is still ~2.5x of JKS (when reading from a ByteArrayInputStream).
>> I guess the major reason is that there is no length field for the cert, so we must read-and-check all the time.
> 
> Could you store the length as an attribute, perhaps?

I'm reluctant to do that. This means people cannot edit the file with a text editor and have to use keytool to manage it.

Of course, this file is still PEM and can be used by other tools, just that they should not try to modify it.

I'll see if there are other ways to improve the performance. One way I'm thinking about is to read the first few bytes of a cert to find out the length (It's always also 30 82 AB CD...).

Thanks,
Max

> 
> --Sean
> 
>> --Max
>>> On Aug 14, 2019, at 9:31 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> On 8/13/19 10:19 PM, Weijun Wang wrote:
>>>>> I will also pass a pretty large cacerts with public CA and our CAs and
>>>>> see wether your parser doesn't choke on it.
>>>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement.
>>> 
>>> This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988
>>> 
>>> I would not want to see a regression in performance.
>>> 
>>> --Sean