Hi Sergey, yes, the backport for 8233228 was also involved, and I am ready to push it.
However, the webrev for 8233228 [1] does not contain a changeset, only a raw patch without meta information. Could you please re-create the webrev to include the changeset? Thanks, Andrew [1] http://cr.openjdk.java.net/~alexsch/sercher/8233228.7u/webrev.00/ On 06/04/2021 17:57, Sergey Chernyshev wrote: > Hi Andrew, > > Thank you for pushing this. Did your testing by any chance involve the > mentioned JDK-8233228 patch? I will definitely need your help again. > > Thanks, > > Sergey > > On 4/6/2021 3:30 PM, Andrew Brygin wrote: >> Hi Sergey, >> >> the backport for 8035166 has been pushed to jdk7u: >> https://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/477f973265c8 >> >> Thanks, >> Andrew >> >> On 05/04/2021 17:54, Sergey Chernyshev wrote: >>> Hi Andrew, >>> >>> Thank you for the review. Yes I need your help to push this. >>> >>> Thanks, >>> Sergey >>> >>> On 4/5/2021 11:08 AM, Andrew Brygin wrote: >>>> Hello Sergey, >>>> >>>> the fix looks fine, our testing does not reveal any problem. >>>> >>>> Please push this change into jdk7u. Do you need any help with push? >>>> >>>> Thanks, >>>> Andrew >>>> >>>> On 20/03/2021 03:49, Sergey Chernyshev wrote: >>>>> Dear colleagues, >>>>> >>>>> Bumping the review thread for backport of JDK-8035166 to 7u. This patch >>>>> is needed for JDK-8233228, reviewed here [1]. >>>>> Please note this is the version .01 updated patch. The old review thread >>>>> is FYI [2]. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8035166 >>>>> 7u webrev: >>>>> http://cr.openjdk.java.net/~alexsch/sercher/8035166.7u/webrev.01/ >>>>> jdk8u commit: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b8ad41e9571f >>>>> >>>>> The patch did not apply cleanly. Here's the what changed, compared to 8u: >>>>> >>>>> * in DOMKeyValue.java updated package name for classes ECParameters, >>>>> NamedCurve. >>>>> * context difference in ECKeyPairGenerator.java >>>>> * copyright notes in SunECEntries, ECParameters, NamedCurve, CurveDB >>>>> were updated >>>>> * context change in SunPKCS11.java >>>>> >>>>> The following tests were run. >>>>> >>>>> com/sun/crypto/provider >>>>> com/sun/security >>>>> java/security >>>>> javax/crypto >>>>> javax/net/ssl >>>>> javax/security >>>>> javax/xml/crypto >>>>> sun/security >>>>> >>>>> Thank you. >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/jdk7u-dev/2021-March/011100.html >>>>> [2] >>>>> https://mail.openjdk.java.net/pipermail/jdk7u-dev/2020-December/011069.html >>>>> >>>>> >>>>> On 3/11/2021 7:18 PM, Sergey Chernyshev wrote: >>>>>> Hi Andrew, >>>>>> >>>>>> What would you think be the target 7u release for JDK-8035166? >>>>>> >>>>>> Does the patch look good to you? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Sergey >>>>>> >>>>>> On 16.12.2020 23:42, Andrew Hughes wrote: >>>>>>> On 18:04 Tue 15 Dec , Andrew Brygin wrote: >>>>>>>> Hello Sergey, >>>>>>>> >>>>>>>> thanks for the clarification, I see that JDK-8035166 is a prerequisite >>>>>>>> for JDK-8233228. >>>>>>>> >>>>>>>> The 8u backport for JDK-8035166 has been pushed into jdk8u-dev, and >>>>>>>> has >>>>>>>> fixVersion openjdk8u292 (April 2021). Most likely, 8u backport of >>>>>>>> JDK-8233228 will be available in the same release. >>>>>>>> >>>>>>>> It would be natural that these fixes should appear in 7u only after >>>>>>>> 8u, >>>>>>>> in April 2021. Unfortunately, at the moment jdk7u does not have a dev >>>>>>>> repo to accumulate fixes for next release. If you do not mind, I would >>>>>>>> propose to postpone the push of JDK-8035166 to the April release cycle? >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Andrew >>>>>>>> >>>>>>> I'm still quite nervous about even including this in 8u, so I would >>>>>>> definitely wait until it has had more time to soak there before >>>>>>> considering it for 7u. >>>>>>> >>>>>>> I'll be reviewing JDK-8233228 for 8u shortly and it'll very likely be >>>>>>> in 8u292. I wish there was a way of working around the need to move >>>>>>> the classes into rt.jar, but I can't see one, other than duplicating >>>>>>> the code and having to maintain two copies. >>>>>>> >>>>>>> Thanks,
