On Wed, 6 Apr 2022 16:00:10 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> Anyone can help review this javadoc update? The main change is the wording >> for the method javadoc of >> Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording >> is somewhat restrictive and request is to broaden this to accommodate more >> scenarios such as when null can be returned. >> The rest are minor things like add {@code } to class name and null, and >> remove redundant ".". >> >> Will file CSR after the review is close to being wrapped up. >> Thanks~ > > src/java.base/share/classes/javax/crypto/Cipher.java line 1053: > >> 1051: * <p>If this cipher has been previously initialized with >> parameters, >> 1052: * this method returns the same parameters. Otherwise, this method >> may >> 1053: * return a combination of user-supplied, default and randomly >> generated > >> ... a combination of user-supplied, default and randomly generated parameter >> values ... > > Other than init(), which APIs could impact the user-supplied parameters? Is > it the getInstance()? > > Is it OK to just use the provider-specific default values instead, by > replacing the "a combination of user-supplied, default and randomly generated > ..."? I am thinking just init() as it takes parameters. Let me take a second look at various Cipher algorithm implementations and see if this can be further pared down. ------------- PR: https://git.openjdk.java.net/jdk/pull/8117