Hi, When reaching out to the BouncyCastle community regarding the deprecated javax.security.cert APIs, I got some interesting feedback from Matti Aarnio of Methics Ltd:
Long ago we did encounter problems with JRE's X509CertImpl.java class, and > more so with X509CRLImpl.java. Both have internal caches of binary form > input that is then converted to parsed forms. Especially the CRL cache did not (still does not?) have nice "that version > is obsoleted, drop it to garbage collection" handling of parsed CRLs, while > it had way too large cache size. > A server running for months and getting a new CRL every 12 hours > eventually grew the memory footprint of obsolete parsed data up to > ridiculous amounts of gigabytes of heap footprint. Once we realized that also certificate parser had such a cache and that > there is no official way to control that cache, we became very much averse > of using those APIs. It seems the lack of cache control of these static implementation caches can be problematic, especially in the CRL case. The default for both caches is a max number of entries of 750 with an unlimited lifetime. The inability of expiring outdated CRLs seems particularly problematic for Matti. A similar issue was reported in JDK-8059007 back in 2014, with the following comment from Sean: We need to introduce some system properties (or something similar) to allow > the crl/cert caches to be adjusted. Changing to RFE. While it would certainly be nice to add some form of cache control, the solution space is large: -1: Remove the cache. One could claim that the parser/factory level is the wrong level to introduce parsing. There are so many ways to tune parsing, there exists many excellent libraries. If apps need caching, they should take care of it at the app level. 0: Do nothing, there haven't been that many complaints 1: Add an option to entirely disable the cache such that apps can do their own caching (or not) without wasting space in the default cache. 2: Add two system properties to control max entries of the cert and crl cache. Setting these to 0 would disable the cache. 3: Add four system properties to control max entries and max lifetime for each of the cert and crl caches. Setting max entries to 0 would disable a cache. 4: Tune the default max entries and lifetime to make everyone happy. 5: Add a pluggable API to control caching. Think AbstractCacheControllingMaxEntrySizeProxyFactoryContext :-) 6: Something I did not consider. -1 is probably not desired/possible because of the behavioural change. 1 is simple but very constrained. 2 and 3 are similar in shape where 3 allows more flexibility introducing lifetime. 4 seems like wishful thinking. You could probably guess I'm not a big fan of 5. 6 seems promising :-) I have a sketch implementation of 3 available, but it would be great to gather some opinions before I put more work into this: https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:x509factory-cache-config Thanks, Eirik. [1] https://bugs.openjdk.org/browse/JDK-8059007
