[8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support

[Martin Balao]

On 8/21/20 5:30 AM, Andrew Haley wrote:
> On 20/08/2020 18:20, Andrew Hughes wrote:
>> On 17:26 Wed 19 Aug     , Andrew Haley wrote:
>>>>
>>>> On 8/5/20 11:54 PM, Andrew Hughes wrote:
>>>>> I didn't go further with the review of this so far, because
>>>>> JDK-8144539 is one of the outstanding test backports for the
>>>>> SQLite patch as well. I intend to return to that bug trail
>>>>> shortly, and we can reconsider both patches once the test
>>>>> backports are resolved.
>>>>
>>>> I believe that 8144539 should not be a blocker for 8080462 because:
>>>> the overlap/conflict between them does not appear to be fundamental
>>>> -and has been addressed in the current backport proposal-; 8144539
>>>> does not look like a trivial backport -at least at first glance,
>>>> given the number of files affected-; and, 8144539 does not seem to
>>>> have the same priority than 8080462 -so a low priority backport is
>>>> currently blocking a high priority one-. Looks to me that 8144539 is
>>>> not even required for compatibility between JDKs, but 8080462
>>>> certainly is.
>>>
>>> We can't wait any longer for this. Martin, please feel free to commit
>>> http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.01/
>>
>> I'm working on the dependencies for this right now. A few days is
>> hardly going to matter.
>>
>> I'll then review Martin's fix.
> 
> It has already been reviewed; it doesn't need another one. As Martin
> explained, we have a case of priority inversion here, where an
> important fix with customer need is blocked by a "wouldn't it be
> nice..." test fix, which doesn't make any sense.
> 
> Martin may, of course, wait for 8144539 if he wishes.
> 

Thanks to both of you for having a look at this.

As long as we can push 8228835 and 8251117 (blocked by 8080462) before
the cut-off date, I'm okay. Please note that 8228835 and 8251117 are not
the only backports blocked by 8080462.

Yes, it's inversion of priorities in a context where we all have many
things with high priority on our backlogs, deadlines coming and users
who have been waiting for months. Even if a few more days or a few more
dependencies don't seem to make a big difference in cost, everything
adds up. I'm making this point not to point anyone but as a call to
judge whether a dependency is fundamental to block a backport. I've the
impression that other JDKs don't go as deep as we are going with
dependencies, and are able to move faster on other -probably more
important- backports. That's my view at least.

Thanks,
Martin.-