Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8

Andrew Dinn adinn at redhat.com
Mon Dec 9 13:53:25 UTC 2019


On 09/12/2019 11:42, Andrew Haley wrote:
> On 12/9/19 11:08 AM, Andrew Dinn wrote:
>> On 09/12/2019 11:05, Andrew Haley wrote:
>>> On 12/9/19 10:55 AM, Andrew Dinn wrote:
>>>> That said, I can see Volker's point here. Putting the changes into both
>>>> 8u40 and 8u252 appears to add an extra redundant step as far as the
>>>> OpenJDK project is concerned. Is there a reason why the 8u40 backport is
>>>> needed? (more specifically, why does it need to be adopted as the RI?)
>>>
>>> I think that's because it's a specification change, and all spec changes
>>> need a reference implementation.
>>
>> Well, yes, of course. But the question was why 8u40 needs to be the RI?
> 
> Oh, I see. I think the idea is that one RI is updated with the minimal changes
> to go to the next. To do otherwise would require Oracle to sanctify a code base
> that they've never looked at. They'd have to be very brave.  :-)
Ah ok, I see. So, both sets of patches are needed to make sure that the
RI and the latest release are mutually in sync with the API spec and
with each other.

In which case the answer to Volker's question appears to be that the
risk mitigation he proposes (defining the API changes and patching 8u252
before attempting to patch 8u40) is not actually a mitigation. An 8u252
which complies with an updated API spec but lacks an accompanying RI
fails to be compliant by virtue of having an incomplete spec with which
to comply (since compliance only exists when you have an API spec + RI).
QED?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill



More information about the jdk8u-dev mailing list