Friday, 17 February 2017, 8:00 am PST
Follow up on action items from last meeting. Review materials submitted by Working Group members.
PMO: Heather VanCura, Patrick Curran
Oracle: Georges Saab, Brian Goetz, Calinel Pastauneu
Azul: Matt Schuetze, Simon Ritter
Fujitsu: Mike DeNicola
Hazelcast: Christoph Engelbert
Intel: Michael Berg
MicroDoc: Hendrik Hoefer
Red Hat: Scott Stark
SAP: Volker Simonis
Twitter: Tony Printezis
We discussed the EC perspective and concern with late filing of JSRs; some EC members feel they are being asked to rubber-stamp work that has been completed. However, we have always said don't innovate in a standards body – we encourage innovation in open-source, collaborative development, and then standardize later.
There is not access to formal specs until very late in the development cycle. Some want formal specs earlier – they don't want to have to poke around in the code to figure out what's going on.
We have discussed that a potential theme for the JCP.next theme could be enabling collaborative RI development and implementation. Since the JCP was created in a time when the waterfall model was popular, the procedures reflect that, but now iterative/agile/collaborative development is more common.
We then discussed the OpenJDK perspective. There is a desire we develop and move faster. Other technologies (C#, Go, Node move quickly) - Java SE moves very slowly; we want people to have access to new stuff much more quickly - access to small incremental improvements more quickly. Since the JCP Process was defined in a different time, when the code was closed. We made changes to make things more transparent. Now we have opened things up to the OpenJDK community. There is an nderstanding that some people doing independent implementations and are actively participating in OpenJDK. The team does produce weekly drops (156 so far for Java SE 9) - these are available under licensing terms (thanks to MikeM for analyzing the licenses).
What can we do to meet the requirements of the process but also do regularly, more lightweight? The Java SE team wants to provide the spec materials in a more automated manner while meeting the licensing terms. The crown jewel is the spec not the implementation. The JCP is critical to that process. The desire is to respond to the business needs to be more transparent and agile while meeting the requirements of the process.
EC Members responded with comments. Matt (Azul): The spec is very important but let's not forget the TCK. This has not been available until very late in the development. cycle. Spec + JavaDoc is good but we also need intermediate drops of the TCK.
Patrick: surprised to learn that the OCTLA isn't being used to give access to the TCK to contributers to OpenJDK - it's only retrospective (available for SE 8 now, but not for SE 9).
Volker (SAP): note that most participants in OpenJDK are not doing independent implementations.
Matt: Azul plays both roles. Have both an independent implementation and also an OpenJDK implementation. Azul is leading the OpenJDK effort for SE 6.
Volker: understands that the Java SE team wants to move faster. He is also concerned about activities happening for future releases as well as for current releases. Licensing model for this work needs to be JCP-friendly.
Brian (Oracle): responds that the future work is released under the standard JCP eval license. We will make the drops available under the evaluation license.
We also discussed simplifying the process of submitting materials to the PMO for review. Brian had said EDR submission duplicated effort. Patrick said we don't define the format of a spec. You can provide a series of links to materials (javadoc, written draft specs) that you've already created. Must snapshot - list specific versions. It was also noted that we should not confuse OpenJDK and Java SE.
Licensing of intermediate "drops" was discussed, specifically, do interim licenses inhibit independent implementors from doing their own parallel development and to make their own interim releases to their communities? Brian clarified that Oracle does want to meet the JCP requirements; you are allowed to develop and distribute, but there are constraints on the terms on which you will distribute interim artifacts before the development process is completed.
Other items for later discussion:
Incubator modules (see the Register article).
TCKs: how do IP rights flow when you're using a continuous development model.
More generally, when does IP vest? Only on completion. Can we fix that given Legal's prohibition on JSPA changes?
Next WG Meeting to be scheduled by Heather via Doodle poll.