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

[Volker Simonis]

On Mon, Dec 9, 2019 at 2:53 PM Andrew Dinn <adinn at redhat.com> wrote:
>
> 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?

Sorry, but I don*t understand your reasoning. There is no "reference
implementation" for a specific update release. There's a "reference
implementation" per JSR. For Java SE 8 (i.e. JSR 337 - Maintenance
Release 2 [1]) this is OpenJDK 1.8.0u40-b25 [2]. Every implementation
which passes the TCK can act as a "reference implementation", that's
up to the Spec Lead. In the JSR 337 [3], the Spec Lead states "The
source code for most of the Reference Implementation will be developed
in the OpenJDK Community".

So obviously the Spec Lead can decide to base the "reference
implementation" for "Maintenance Release 3" on OpenJDK 1.8.0u40-b25.
But in contrast to previous Maintenance Releases, this will be a
version, that nobody wants (because it misses a bunch of fixes and
features) and nobody will be able to use (because it misses even more
security patches). It would also give Oracle an competitive advantage
if they were the only ones who could release a MR3 compatible version
of 8u252 in April because the community needs more time to port the
corresponding changes from 8u40 to 8u252. And it doesn't help that (as
Iris wrote) "even if [the OpenJDK version of] 8u252 does not include
the ALPN and RSASSA-PSS changes, those who work on that release line
or deploy compatible Java implementations based on code derived from
OpenJDK would still have 120 days to make it compliant, per the
License Grant section of the TCK License". We would have two versions
of 8u252 where only the Oracle one would be Java SE 8 MR3 compatible,
while the OpenJDK one would be still MR2 only.

Summing it up, I don't think that the current OpenJDK development
version has any problems passing the current Java SE 8 MR2 version of
the TCK (we're all testing that regularly, right :). That's why I
don't see any reasons not basing the reference implementation of Java
SE 8 MR3 on it (i.e. 8u252). Basing it on 8u40 would be just a
needless duplication of efforts.

Fortunately, Iris just wrote in her follow-up answer that "work is
underway to contribute the changes to 8u252 in time for the April 2020
release", so hopefully, both, the OpenJDK as well as Oracle JDK will
be able to support the new Java SE 8 MR 3 features at the same time in
April 2020.

Best regards,
Volker

[1] https://jcp.org/aboutJava/communityprocess/mrel/jsr337/index2.html
[2] http://jdk.java.net/java-se-ri/8
[3] https://www.jcp.org/en/jsr/detail?id=337

>
> 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
>