We cannot upgrade Jetty if we stay on JDK11, which is my biggest concern about it.
> On Aug 19, 2025, at 19:11, Christopher <ctubb...@apache.org> wrote: > > Sorry for the confusion. I linked that PR mostly for my own reference > to review to make a new PR. You can ignore that PR for now. I would > create a new one for this. I was getting ahead of myself, because I > know that bumping the minimum build version would also include a bump > of the Apache parent POM, which also means some other related POM > cleanup. That linked Draft PR is not related to this, except it > contains some general POM cleanup that would be good to include when > bumping the Apache parent POM. > > I was thinking: > > * release 3.8.5 (that will not benefit from these changes, and needs > to be EOL ASAP) > * optionally release 3.9.4 (this action is not a blocker for 3.9) > * create a PR that bumps the Apache parent POM, establishes the > minimalJavaBuildVersion as 11 (or 17), and performs related POM > cleanup (keep Java 8 as the target version) > * apply that PR to 3.9 and master > * create a PR that bumps the target version for Java to 11, and apply > to master only > * release 3.10 > > I would not bump the target Java version for runtime to 17 for the > 3.10 branch. I would wait for 4.0 for that. I would keep it at 11. The > build version can be 11 or 17. > > On Tue, Aug 19, 2025 at 6:18 PM Andor Molnar <an...@apache.org> wrote: >> >> Okay. I checked the pull request that you linked and there’s a lot more in >> that most of which I don’t even understand. I suggest the following: >> >> - let’s finish that PR by adding minimum build version of JDK 11 for now, >> - merge the PR to all active branches: master, branch-3.9 and branch-3.8, >> - release 3.9.4 and 3.8.5, >> - create another patch which bumps the minimum build _and_ runtime version >> to JDK 17 on the master branch only, >> - release 3.10.0. >> >> wdyt? >> >> I’d like to keep the minimum required build version to JDK 11 on the stable >> branches 3.8 and 3.9. Does it make any sense? >> >> Andor >> >> >> >> >>> On Aug 19, 2025, at 13:12, Christopher <ctubb...@apache.org> wrote: >>> >>> Thanks for bringing my suggestion to the mailing list for discussion. >>> >>> I wasn't aware that 17 was being considered. Is there another >>> discussion thread I can read about that? >>> >>> My suggestion could apply with JDK 17 instead of 11. I didn't suggest >>> 17 because I thought 11 would be more acceptable as a smaller >>> incremental jump. However, if there is already a goal to move to 17, >>> then applying my suggestion with JDK 17 as the minimum would be a good >>> first step. Making the minimum build version 11 or 17 could be done on >>> all active branches. Changing the target runtime version to 11 or 17 >>> should only happen in the main branch, and can be done later, when the >>> project is ready for that. Bumping the minimal build version is >>> independent of bumping the target version for runtime. >>> >>> The Maven enforcer setting task is run automatically with newer Apache >>> parent POMs (see >>> https://repo1.maven.org/maven2/org/apache/apache/35/apache-35.pom). ZK >>> uses an older version and it needs to be updated anyway. >>> >>> If bumping the build version to 11 or 17 is agreed, I volunteer to >>> create a PR for it. I would probably also revisit my earlier PR to >>> remove maven-antrun-plugin >>> (https://github.com/apache/zookeeper/pull/2241) because there are some >>> general POM cleanup stuff in that PR that would probably be good to >>> borrow from that PR to include in a POM update. >>> >>> On Mon, Aug 18, 2025 at 10:37 AM Andor Molnar <an...@apache.org> wrote: >>>> >>>> Hi team, >>>> >>>> Christopher has a suggestion on the Owasp upgrade PR which I think we >>>> should discuss here. >>>> >>>> TL;DR - Since Owaps requires Java 11 after upgrade, let's bump the minimum >>>> required Java version for _BUILDING_ ZooKeeper to 11 across all build >>>> profiles. >>>> >>>> That additional change will allow lots of plugins to be updated that >>>> require newer Java versions, but the maven.compiler.release property set >>>> to 8 in the ZK pom.xml would still keep ZK compatible with Java 8 at >>>> runtime. >>>> >>>> … >>>> >>>> I think it's an inconvenience to have two separate minimum versions, >>>> depending on which tasks one executes. Also, there are other reasons to >>>> standardize on the minimum being JDK11 for everything: >>>> >>>> • in this case, only OWASP requires a different minimum JDK... but next >>>> time, a plugin that is part of the main build might require JDK11. Making >>>> JDK11 the minimum for everything would help avoid such problems in the >>>> future, >>>> • older JDK versions are increasingly harder to acquire in newer >>>> operating systems and corporate environments where security policies >>>> prevent the use of older software, so fewer people over time are actually >>>> building and testing with JDK8; so, continuing to support it is >>>> increasingly a waste of effort, >>>> • JDK11 has stricter Java 8 compliance enforcement than JDK 8 does, so >>>> it's better to build with JDK11 if you want to support JRE8. >>>> >>>> See the full conversation here: >>>> https://github.com/apache/zookeeper/pull/2297 >>>> >>>> I think this is acceptable, but not sure if it’s worth the effort since >>>> we’re going to upgrade to JDK 17 project-wise anyways. >>>> >>>> Consider that with this change we have to do the following: >>>> - modify maven enforcer settings in parent POM, >>>> - add documentation changes explaining the situation, >>>> - remove JDK8 github actions, >>>> - change Apache CI Jenkinsfile and remove JDK 8 builds completely. >>>> >>>> It’s also true that JDK 17 upgrade is not going to happen tomorrow. >>>> >>>> Please share your thoughts. >>>> >>>> Regards, >>>> Andor >>>> >>>> p.s. I don’t find the maven enforcer setting myself which needs to be >>>> bumped in parent pom, but if someone can point me to it or even create a >>>> PR with the above mentioned changes, I’d much appreciate that. >>>> >>>> >>
