But JDK-8346720 does not sound like only spec change. It needs real code and a change to SunPKCS11 Provider doc (which is not a spec).
This is my suggestion: 1. Re-open JDK-8346720, but you can cover the code change in PR #22215. 2. We will create a sub-task for it to update the SunPKCS11 Provider doc. 3. The Standard Name change can be combined into JDK-8346997 or stay inside JDK-8346720. The CSR for JDK-8346720 is still needed because it has at least the SunPKCS11 Provider change part. This is also the reason why JDK-8346720 needs to be re-opened. Thanks, Weijun > On Jan 8, 2025, at 18:35, Martin Balao <mba...@redhat.com> wrote: > > Hi Weijun, > > Happy new year to you as well! > > Thanks for the heads up. My understanding is that the spec changes will be > done in JDK-8346997 and the code changes will be integrated as part of > "8328119: Support HKDF in SunPKCS11 (Preview) (PR #22215)", so we don't have > to create dependent PRs. Has there been any plan change since we reached this > agreement? > > Regards, > Martin.- > > > On Tue, Jan 7, 2025 at 11:44 AM Wei-Jun Wang <weijun.w...@oracle.com> wrote: > Hi Martin, > > Happy New Year! > > I’m currently working on > > 8346997: Java Security Standard Algorithm Names spec should include key > algorithm names > https://bugs.openjdk.org/browse/JDK-8346997 > > As you can see, it involves only spec changes. > > Some days ago, we asked you to close out 8346720: Support Generic keys in > SunPKCS11 SecretKeyFactory (https://bugs.openjdk.org/browse/JDK-8346720) > because it’s closely related to the enhancement I’m working on. However, I > believe your enhancement may require real code changes, which might be better > handled separately. > > It might make sense to re-open JDK-8346720. I could still include the > Standard Names changes for SecretKeyFactory.Generic in my enhancement, > leaving just the SunPKCS11 Provider changes for you. > > What do you think? > > Thanks, > Weijun >
