[jsr369-experts] [ADMIN] Meeting notes and audio from 20161101 ALPN Backport Meeting

From: Edward Burns <edward.burns_at_oracle.com>
Date: Tue, 1 Nov 2016 06:13:42 -0700

Hello Volunteers,

Thanks everyone for calling in and constructively contributing.

Audio of call available at

Action items indicated with =>.

Goal: Approach defining first draft of API for backport of ALPN to JDK8.


* Give Greg a chance to walk through some code scenarios to hopefully
  make the case for an API change in JDK 9 regarding the ALPN API and
  Cipher negotiation. Greg will verbally share the code snippets in the
  meeting using pastebin urls, such as
  <https://pastebin.mozilla.org/8922336>. The only thing Greg need
  share is the number to allow the rest of us to see it.

  Greg prepared a Google Doc:


* If the stakeholders cannot agree on the need for a change, re-affirm
  that we are not asking for API changes.

* Sketch out backport for JDK8

* Plan next steps

Meeting notes

Roll call

Ryan Lubke
Ed Burns
Vincent Ryan
Greg Wilkins
Stuart Douglas
Martin Mulholland
Kevin Sutter
Bill Wigger
Simone Bordet
Mark Thomas
Vinnie Ryan

I. Need to change the JDK9 API?

* Greg walked through his document.

* Vinny: the focus on the cipher selection is not the right focus

  Greg pointed out a special aspect of the HTTP/2 protocol itself that
  indicates that some ciphers are acceptable and some are not.

  Vinny: Why do you have to run the full negotiation?

  Greg: because there is user extensible code in the mix.

  Not just that, it's because the user extensible code may not implement
  the algorithm 100% correctly.

  Simone: added the fact that the JDK could change the algorithm due to
  subsequently discovered need to change due to vulnerabilities.

  Stuart: Just because we can do it now, doesn't mean we'll be able to
  do it in the future.

  Vinny: I'll need to delv into this more. He'll revisit this.

=> Vinny will take the input from this meeting and revisit Greg's
   suggested changes.

II. Sketch out backport

Vinny listed some approach choices:

* System properties based approach.

* Another approach is to use a utility class with static methods


  Use reflection to access the members


* Whatever solution we have to the backport, it must be in 8 only.

Vinny shared the following sketch:


Proposing 4 new methods in the jdk.net package:


public static void setApplicationProtocols(SSLSocket socket, String [] names)
public static String getApplicationProtocol(SSLSocket)
public static void setApplicationProtocols(SSLEngine, String [] names)
public static String getApplicationProtocol(SSLEngine)

=> Vinny will file an OpenJDK bug for the backport. He observed, it's
   gotta be immediate or not at all for the JDK9.

Kevin Sutter asked for timeframe for the backport

=> Vinny said he'd get with his manager to get the timeframe for the

=> Ed will follow up to ensure things keep progressing.

| edward.burns_at_oracle.com | office: +1 407 458 0017