[7u] RFR 8035166: Remove dependency on EC classes from pkcs11 provider

[Andrew Brygin]

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,