RFR: JDK-8308398 Move SunEC crypto provider into java.base

[Anthony Scarpino]

On 6/30/23 4:26 AM, Peter Firmstone wrote:
> 
> On 17/06/2023 11:13 pm, Alan Bateman wrote:
>> On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino 
>> <ascarpino at openjdk.org> wrote:
>>
>>> This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC 
>>> has always been separate from the base module/pkg because of its 
>>> dependence on a native library. That library was removed in JDK 16.
>> The proposed changes look okay, meaning it should be okay to have the 
>> SunEC provider in java.base. However, the motivation isn't clear as 
>> there isn't an issue with JCE providers in java.base using native 
>> code. I know there were non-technical issues with libsunec in the past 
>> but that would haven't prevent the SunEC code form being compiled into 
>> java.base.
>>
>> I assume the main implications of the change is that 3rd party JCE 
>> providers signed with an EC certificate can now be deployed on the 
>> module path.  Another way to solve that issue is that delay 
>> verification of signed JARs until the boot layer is created - if we 
>> did that, would you still want to move the SunEC provider into java.base?
> 
> 
> Curious, the provider mechanism provides a level of indirection, aka 
> service, a boundary or separation.  How are module boundaries defined?
> 
> Regards,
> 
> Peter.

With JCE, there is not specific boundary definition to modules.  I was a 
case-by-case basis at the time the provider was integrated.

Tony