What should the relationship between ports and developers of large projects be?

[Alan Bateman]

We have discussed ports, the suggestion of a "Maintainers" file to list 
the owners of ports and features, and also putting ports into tiers at a 
number of OpenJDK Committers' Workshops. As I recall, it was just 
discussion and there wasn't any proposals to decide or vote on. It's 
been a few years and there are a few additional ports added to the 
OpenJDK project with JEPs. These JEPs have/had owners so there is at 
least a starting point there. As we've seen from the replies, there are 
also a few ports that are maintained in downstream repos. In the early 
days of OpenJDK, the Porters Group was created to help create porting 
projects. The porters-dev mailing list still exists and maybe that is 
another starting point.

As regards JEP 425. I agree with your comment that monster features like 
this should try to integrate early in a release. A big change will 
usually result in a few surprises and follow-up issues to address after 
their initial integration. In this case, we had really hoped to have it 
integrated much earlier but it wasn't to be. These big integrations 
aren't easy to do, esp. with a moving target that is the main line and 
the constant merging and rework to keep the code working and tests 
passing. It's also impossible to know how long the code review and the 
PR for such a feature might take.

You mentioned not noticing the significance of JEP 425 being a preview 
feature and that preview features are not optional. That's a good 
discussion topic as I think several people were surprised by this.  
Every feature release since Java 14 has had preview features but it's 
been preview language features that didn't have a big impact on the 
runtime. Sealed classes and records required some support in the runtime 
when in preview but it wasn't anything that required porting work. JEP 
424 and JEP 425 are the first preview APIs to include big changes to the 
runtime and require porting work to platforms beyond x64 and aarch64. 
It's okay for a port to sit out a release but it might not be necessary 
for 19. For JEP 424, an implementation of the native Linker is optional 
as Maurizio mentioned. For JEP 425 we hope to integrate a non-scalable 
implementation of virtual threads that ports can use in the interim.

So what can we do better? I don't disagree that communication could have 
been better in this case. We did send a heads-up to porters-dev, as you 
noted, but there could have been more communication before the JEP was 
proposed to target and a reminder that preview features are not 
optional. This goes both ways too. If a port is actively maintained then 
it would be helpful to start before the code is final and before the 
feature integrates. I don't know how practical it would to have a "ready 
for porting" milestone in some projects, maybe it would but more likely 
it would be dealing with at least some code shimmer right up to integration.

Thomas Stüfe's suggestion to run a few online meetings with maybe 
design/code walk though is good idea. If we had JVMLS then there would 
have been recorded sessions and probably a few in-person meetings too. 
Thomas also brings up the suggestion to split up large patches into 
smaller chunks. We did try in this case but it was weighted more on the 
libraries side where it was possible to integrate a lot preparatory 
changes and 3 JEPs in advance of the main event. We didn't identify 
significant chunks for the hotspot code that could have integrated in 
advance, maybe we should have tried harder there. With Project Jigsaw 
(JDK 9) we were able to split the project into 3 big 
integrations/milestones and >1000 bite size pieces to prepare the code 
base but we didn't have anything like this here.

-Alan.