jep
jep copied to clipboard
jenkinsci
2+2+2 Java Support Plan
2+2+2 Java Support Plan
Draft documents and other supporting information
- Java 11, 17, and 21 in Jenkins
- Visualizing Java versions for Jenkins
- Jenkins developer mailing list discussion
- Jenkins user mailing list discussion
Governance board video discussion of the proposal
Would like review from:
- @wadeck - security officer
- @dduportal - infrastructure officer
- @kevin27 - documentation officer
- @timja - release officer
- @basil - core maintainer
- @uhafner - board member
- @NotMyFault - board member
- @jtnord - core maintainer
- @daniel-beck - security team
- @jleon33 - CloudBees product manager
None of the reviews are required, but I would be very happy to have inputs and suggestions.
Any plans for Groovy? By default it outputs Java 1.5 bytecode or if you customize the output at most it will output Java 1.8 bytecode when compiling Groovy classes.
Thanks for asking. No plans for Groovy that are part of this JEP. Groovy upgrade is a major project that will need to be considered separately.
@timja thanks for reviewing it. Do you feel that we're at a point where this can is ready for approval as a draft JEP? I'm a JEP editor, so I'm happy to perform the necessary steps. The approval process says:
A JEP editor will check the submission for conformance with JEP structure and formatting guidelines. Editors may make minor changes to make the submission meet the requirements for approval as a Draft JEP. If a JEP requires major changes, editors will add specific feedback and send the submission back to the sponsor for revision. ... Once JEP meets requirements for structure and formatting, the editors will approve the submission as a draft JEP by following the steps outlined in the editors' "Approve as Draft" section. When they are done, the Draft JEP will have an official JEP number and the submission PR will have been merged to a matching folder (for example, jep/1) in the master branch.
If you (as a JEP editor) feel that it is ready for approval as draft, then I'll follow the steps in the "Approve as draft" section so that the proposal is assigned a JEP number.
I'm also fine if we need to wait for review by others before it is assigned a JEP number and listed as a draft JEP.
The more pressing issue from my perspective is rather that this JEP does not have a prototype implementation. Per JEP-1:
Standards Track JEPs consist of two parts, a design document and a prototype implementation. The prototype implementation should be co-developed with the JEP, as ideas that sound good in principle sometimes turn out to be impractical when subjected to the test of implementation.
This is a critical part of the JEP process from my perspective. The fact that it is part of the JEP process reflects the deep wisdom of its designers. How, then, could this PR contain the text
I agree that a prototype is a critical part of the JEP process for standards track JEPs and I very much like your recommendation that we should improve this JEP with checklists for key events like adding a Java version and removing a Java version. I look forward to working with you on the checklists as a way to make this JEP more useful and more effective.
For the sake of precision, I think that a prototype is not strictly required because this is a process JEP as described in the JEP types where it says:
A Process JEP describes a process surrounding Jenkins, or proposes a change to (or an event in) a process. Process JEPs are like Standards Track JEPs but apply to areas other than the Jenkins codebase itself. They may propose an implementation, but not for what would be generally considered the Jenkins codebase; they often require community consensus; unlike Informational JEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Jenkins development. Any meta-JEP (JEP focusing on the improvement of the Jenkins Enhancement Proposal process) is also considered a Process JEP.
It may be that I incorrectly assigned this as a process JEP instead of a standards track JEP, but the things that I was trying to describe seemed to better fit "procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Jenkins development" than "a new feature or implementation for Jenkins".
Since the purpose of this JEP is to institute a new process, I believe that the prototype implementation should be documentation of this new process in the form of checklists, gleaning the relevant insights from the past (where applicable) and proposing new procedures for the future (when past precedent is not applicable).
I like that idea very, very much. I'm happy to work with you to describe the stages and am happy to link to https://github.com/basil/release/tree/java-lifecycle as proposed checklists for the stages of the Java lifecycle.
I see a strong connection between "Require a new Java version" and "Drop support of an old Java version". I assume that the description of "Drop support of an older Java version" will be inside the "Require a new Java version" checklist, since requiring a new Java version infers the end of support for the older Java version. Let me know if I'm wrong on that.
I agree that a prototype is a critical part of the JEP process for standards track JEPs and I very much like your recommendation that we should improve this JEP with checklists for key events like adding a Java version and removing a Java version. I look forward to working with you on the checklists as a way to make this JEP more useful and more effective.
Thanks Mark, I am glad we agree on the basic premise and I am happy to help make this a reality.
For the sake of precision, I think that a prototype is not strictly required because this is a process JEP as described in the JEP types […] It may be that I incorrectly assigned this as a process JEP instead of a standards track JEP, but the things that I was trying to describe seemed to better fit "procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Jenkins development" than "a new feature or implementation for Jenkins".
I am not sure, and I am not particularly interested in debating the letter of the law, either. From my perspective, the spirit of the law is that architects are obligated to reify their abstract proposals with concrete prototypes in order for the abstract proposals to have merit. This has not yet been done for this JEP, and the result is that some critical design areas remain ambiguous, so my blocking feedback remains.
I like that idea very, very much. I'm happy to work with you to describe the stages and am happy to link to https://github.com/basil/release/tree/java-lifecycle as proposed checklists for the stages of the Java lifecycle.
Well, I was not volunteering to drive the prototype implementation myself, at least not within the context of the current PR, of which I am not the author. I was merely offering the above as a starting point to help the current PR's author (i.e. you) reify their proposal and thereby bring it up to the standard by which I would approve a JEP. If you do not have the time or interest to drive this, then that is quite alright, but in that case I will file a competing JEP that does meet my standards, including having a complete prototype implementation in the form of the checklists I described, with the work being driven by me. Sorry, but I strongly believe there needs to be a connection between architecture and implementation.
I see a strong connection between "Require a new Java version" and "Drop support of an old Java version".
Yes, I used these terms interchangeably in my post above, preferring one term over the other simply to emphasize the point that the next time we do this will be quite different from the last time we did this.
I was merely offering the above as a starting point to help the current PR's author (i.e. you) reify their proposal and thereby bring it up to the standard by which I would approve a JEP. If you do not have the time or interest to drive this, then that is quite alright, but in that case I will file a competing JEP that does meet my standards, including having a complete prototype implementation in the form of the checklists I described, with the work being driven by me.
I have the interest and I hope to have the time to drive it. If I find that I don't have the time to drive it, I will certainly let you know so that I can close this pull request and let you submit a pull request with the desired checklists.
I've already found great value in my reviews of the tickets and pull requests that are examples of "Add a new Java version".
I realize that your blocking comment is on the "Drop support for a Java version", but I want to capture the easier checklist first. I think that the detailed checklist for "Add a Java version" will be good seed material for the "Drop support for a Java version" checklist.
I am hitting the "Request Changes" button on this PR specifically for this last issue: the question of how to drop support for Java versions in the future with regard to the build toolchain is an important design conversation that I believe should happen in the context of this JEP rather than postponed until later. Experience shows that it is better to get disagreement and debate out of the way upfront rather than to have it once the implementation of a project is underway.
I thought about the "require a new Java version" problem some more today and came to some concrete points:
- Unlike the changes to require Java 11, the POM changes to require Java 17 are much less invasive: at the present time, everything is defined in terms of the
maven.compiler.releaseandmaven.compiler.testReleaseproperties (currently set to 11). We could even definemaven.compiler.testReleasein terms ofmaven.compiler.releaseif desired to bring the number of property knobs down from 2 to 1. - With the changes to require Java 11, I attempted to write logic in
maven-hpi-pluginto dynamically set Maven properties based on the Jenkins core version, but it was impractical. While it worked for command-line builds, it generally did not work for IDEs and thus caused more confusion. While Maven does allow you to set Maven properties from within a Maven plugin mojo, IDEs generally don't run these mojos and will therefore use the defaults instead. - The current interface between parent POMs and consumers is for the parent POM to declare the
maven.compiler.releaseandmaven.compiler.testReleaseproperties and for the consumer not to declare anything. One option would be to follow a similar process to the one we followed for requiring Java 11, where we release new parent POMs that require Java 17 and accept that plugins with an older baseline (which, on day 1, will be all of them) won't be able to get parent POM updates until they start requiring a newer baseline, likely 3-4 months down the road. I am not sure if that is a precedent that we want to set for the long term, since breaking parent POM updates is a pretty big disadvantage. We did manage to tolerate this strategy last time around, in part because of my Maven HPI plugin hack to dynamically set the property (which didn't work in IDEs). - Another option is go back to the older system of plugin consumers declaring both a Jenkins core version and a Java version. We might want to add Maven HPI plugin logic to validate the consumers aren't trying to do something unsupported, like setting the Java version to anything other than the one that matches the bytecode level of their core baseline. In that case we'd need to do a sweep to re-add that property to popular plugins. Advantages: avoids the flag day mentioned above. Disadvantages: requires a sweep to implement, harder for maintainers to keep these properties in sync and less obvious what the values should be. Though maybe some of these disadvantages could be mitigated if Maven HPI plugin enforced a specific value and failed the build otherwise, at least making it obvious what these values should be?
- There could be other options that I haven't considered. For example, maybe I was overly harsh in my assessment of my previous hack to have Maven HPI plugin dynamically set the property based on the Jenkins core version, even though IDEs won't pick it up. Maybe we adopt one of the options recommended previously but reinstate this hack as a fallback? This is a variation of the previous bullet point, but instead of being a hard error, the Maven HPI plugin would make a best effort attempt to fix up the Java version property, which would likely succeed in CLI builds but fail for IDE builds.
Anyway, this is an example of the type of thing that I consider important to cover within this JEP in order to ensure the completeness of the design. If we don't figure out the plan for things like this upfront, then we'll just have to solve these problems as we encounter them, and by then it may be too late to implement some of these solutions, because it takes a while to propagate HPI plugin and POM changes throughout the ecosystem.
Am I reading this thread correctly, I find no mention that you are removing Support for the Solaris platform, Java 11 is the last currently supported version java that will be supported on Solaris.
Am I reading this thread correctly, I find no mention that you are removing Support for the Solaris platform, Java 11 is the last currently supported version java that will be supported on Solaris.
Oct 2024 is the planned end of life for all Java 11 support in Jenkins. Since Java 17 and Java 21 are not supported on Solaris, Jenkins will not be supported on Solaris after the end of Java 11 support in Jenkins.
As far as I know Peter Tribble is still maintaining an illumos/Solaris OpenJDK port, and Peter's port of OpenJDK 21 is available in his "Tribblix" distribution. I cannot comment on builds/packaging of this port to other distributions, as I am no longer familiar with work in this area.
As far as I know Peter Tribble is still maintaining an illumos/Solaris OpenJDK port, and Peter's port of OpenJDK 21 is available in his "Tribblix" distribution. I cannot comment on builds/packaging of this port to other distributions, as I am no longer familiar with work in this area.
That's great news!
Per the maintainer documentation I am applying the stalled label to this pull request, as it has remained inactive for a month.