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

[Peter Firmstone]

Thanks Anthony,

Always interesting to see how others are managing modularity. Some time 
ago now (circa 2007), Sun released Jini as open source, set up a project 
at Apache called River, we struggled to get developers though, we had a 
big monolithic codebase and developers couldn't get their heads around 
it.   When I was modularising it, I decided to use SPI's as module 
boundaries, it turned out to be a good decision, we ended up making all 
our SPI's OSGi services as well.   Probably doesn't matter in this 
instance, OpenJDK is already modular, and it's implementation detail.   
Some of our crypto providers are in the same module, but I'm thinking of 
separating them into different modules now, as some are no longer 
secure, but some people may still need them for compatibility, by moving 
old code into different modules, we can allow to die a peaceful death, 
without requiring people who don't use it to be burdened by it.

-- 
Regards,
  
Peter

On 4/07/2023 1:28 am, Anthony Scarpino wrote:
>
>
> 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
>
>