Love the write up Henrik :-8
> On Fri, Feb 3, 2023, at 9:20 AM, Henrik Ingo wrote: > > … > 1) I assume JDK17 support is invasive, so that would suggest a feature > branch. However, the next question is, is there any risk involved in this > work (like Falcon for MySQL). Hypothetically it could be that Java 17 has > worse performance than Java 11, or some other blocking problem is > encountered. But in practice we probably estimate that this risk is small. > In such a case JDK17 support could indeed be developed with small patches > directly against trunk, but this would be an exception to the rule! > > The introduction of JDK17 (in progress) has a different challenge to it as well, as it involves small changes on many different repos. This makes a feature branch(es) cumbersome and really doesn't de-risk the final merge. And as Derek you point out, our existing method of introducing and dropping JDK support is clumsy. The JDK17 work includes improving how we do this so it will become easier (the primary tactic here is that the JDKs we support are defined only in build.xml, and other repos read and use it as context), leaving just the work on fixing what actually is broken when using the new jdk. So it's another example of incremental roll out, because of base improvements and then the actual changes in safe incremental steps. To my understanding this wasn't the original desire and consensus with JDK17, folk requested that it be introduced complete, though I cannot actually find the reference to that. I was about to raise a thread asking for us to instead take an incremental approach, to help us move faster and safer, but am doing it here, thanks for raising the thread Josh. As others point out, we can't paint ourselves into the wrong corner with JDK17, though we can't drop JDK8 support until we're out of the (right) corner. ref: - https://lists.apache.org/thread/hny49r5vlg4nn9d53n3fksxvjg71joqz - https://lists.apache.org/thread/s1bntyk3ykovtw0ph48rf5sy2v9ls8qw
