Re: Java 17 features in 2.x
Thanks for the additional replies, I think the distinction between new features for the next version and bug fixes for both versions is a helpful approach. Having contributed and backported a number of changes, I have been more focused on compatibility, but I completely agree that we should take advantage of new features on the main branch. We have already started doing this in terms of certain libraries, and more work is in progress. Regards, David Handermann On Mon, Aug 7, 2023 at 7:54 PM Mark Bean wrote: > I was working on a very similar response. Thanks Joe for the clear > articulation. I agree with this approach 100%. > > Adding one additional point, the differentiation of Java 17 in the NiFi 2.0 > line may encourage and expedite the migration to a new major release. I > think we want to get there as soon as possible rather than continue the > burdensome effort of supporting new main lines of code. > > > On Mon, Aug 7, 2023 at 8:33 PM Joe Witt wrote: > > > The views shared thus far are certainly reasonable but I do want to add > > a different take. > > > > The reason we want to do major releases from time to time is so that we > can > > take advantage of leaps in the language and frameworks we rely on. To > that > > end it would seem unfortunate to not start aggressively taking advantage > of > > that. In particular we've been held to Java 8 standards for at least 7 > > years. I would advocate we allow and even encourage usage of Java 17 > > features/syntax to help move forward. > > > > The point about backporting is important and I agree the 'easiest' way is > > if changes made to main are backportable. Then again we don't really > need > > everything to be backportable and for sure that will start happening less > > and less. If we're talking about 'bug fixes' then it probably makes > sense > > to prefer for now they avoid Java 17 assuming a given fix should target > > both 2.x and 1.x lines. But if we're talking about new features or even > > improvements I think we should be free to move on to Java 17 > > idioms/benefits. If a contrib does this then it just won't go to the 1.x > > line. This atrophy is natural/ok I think and lets us give the 2.x line > the > > attention/growth it deserves. > > > > Thanks > > > > On Mon, Aug 7, 2023 at 2:19 PM David Handermann < > > exceptionfact...@apache.org> > > wrote: > > > > > Mike, > > > > > > Thanks for raising the question. Following Matt's comments, I recommend > > > minimizing use of Java 17 features to make it easier to backport > changes > > > for now. > > > > > > Incremental adjustments can be done when backporting, but it requires > the > > > author and reviewer to pay careful attention since the GitHub automated > > > builds for the main branch run on Java 17. > > > > > > As Matt recommended, the alternative is to provide separate pull > requests > > > for the main and support branches. > > > > > > We already have a few Java 11 and 17 references on the main branch for > > > things like List.of(), and most of these are easy to adjust when > > > backporting, but they do require careful attention. > > > > > > Regards, > > > David Handermann > > > > > > On Mon, Aug 7, 2023 at 4:04 PM Matt Burgess > > wrote: > > > > > > > In my opinion that's ok, but I think it would be helpful if a PR is > > > > going to be backported to support/nifi-1.x that the PR author > provides > > > > two PRs, one against main with Java 17 features and one against > > > > support/nifi-1.x with Java 8 features. That being said, allowing Java > > > > 17 features may make maintenance tougher while there's an active 1.x > > > > branch. Maybe we should wait until we only support NiFi 2.x? > > > > > > > > On Mon, Aug 7, 2023 at 4:59 PM Mike Thomsen > > > > wrote: > > > > > > > > > > Since we're standardizing on 17, we're free and clear to use Java > 17 > > > > > features, right? > > > > > > > > > >
Re: Java 17 features in 2.x
I was working on a very similar response. Thanks Joe for the clear articulation. I agree with this approach 100%. Adding one additional point, the differentiation of Java 17 in the NiFi 2.0 line may encourage and expedite the migration to a new major release. I think we want to get there as soon as possible rather than continue the burdensome effort of supporting new main lines of code. On Mon, Aug 7, 2023 at 8:33 PM Joe Witt wrote: > The views shared thus far are certainly reasonable but I do want to add > a different take. > > The reason we want to do major releases from time to time is so that we can > take advantage of leaps in the language and frameworks we rely on. To that > end it would seem unfortunate to not start aggressively taking advantage of > that. In particular we've been held to Java 8 standards for at least 7 > years. I would advocate we allow and even encourage usage of Java 17 > features/syntax to help move forward. > > The point about backporting is important and I agree the 'easiest' way is > if changes made to main are backportable. Then again we don't really need > everything to be backportable and for sure that will start happening less > and less. If we're talking about 'bug fixes' then it probably makes sense > to prefer for now they avoid Java 17 assuming a given fix should target > both 2.x and 1.x lines. But if we're talking about new features or even > improvements I think we should be free to move on to Java 17 > idioms/benefits. If a contrib does this then it just won't go to the 1.x > line. This atrophy is natural/ok I think and lets us give the 2.x line the > attention/growth it deserves. > > Thanks > > On Mon, Aug 7, 2023 at 2:19 PM David Handermann < > exceptionfact...@apache.org> > wrote: > > > Mike, > > > > Thanks for raising the question. Following Matt's comments, I recommend > > minimizing use of Java 17 features to make it easier to backport changes > > for now. > > > > Incremental adjustments can be done when backporting, but it requires the > > author and reviewer to pay careful attention since the GitHub automated > > builds for the main branch run on Java 17. > > > > As Matt recommended, the alternative is to provide separate pull requests > > for the main and support branches. > > > > We already have a few Java 11 and 17 references on the main branch for > > things like List.of(), and most of these are easy to adjust when > > backporting, but they do require careful attention. > > > > Regards, > > David Handermann > > > > On Mon, Aug 7, 2023 at 4:04 PM Matt Burgess > wrote: > > > > > In my opinion that's ok, but I think it would be helpful if a PR is > > > going to be backported to support/nifi-1.x that the PR author provides > > > two PRs, one against main with Java 17 features and one against > > > support/nifi-1.x with Java 8 features. That being said, allowing Java > > > 17 features may make maintenance tougher while there's an active 1.x > > > branch. Maybe we should wait until we only support NiFi 2.x? > > > > > > On Mon, Aug 7, 2023 at 4:59 PM Mike Thomsen > > > wrote: > > > > > > > > Since we're standardizing on 17, we're free and clear to use Java 17 > > > > features, right? > > > > > >
Re: Java 17 features in 2.x
Matt Yeah that is a good summary of it. We want to help the community move NiFi forward along with Java's advances and these major line breaks are the best opportunity to do so. We're in effect making a bet on a given line or set of Java lines for quite some time so we should take advantage of that. Joe On Mon, Aug 7, 2023 at 5:51 PM Matt Burgess wrote: > That's a fair point and I think represents the way we want to go > forward. If I understand correctly, you're saying bug fixes meant for > both lines shouldn't need/use Java 17 features but new capabilities > for 2.0 should encourage the use of Java 17 features when prudent? > > Thanks, > Matt > > On Mon, Aug 7, 2023 at 8:33 PM Joe Witt wrote: > > > > The views shared thus far are certainly reasonable but I do want to add > > a different take. > > > > The reason we want to do major releases from time to time is so that we > can > > take advantage of leaps in the language and frameworks we rely on. To > that > > end it would seem unfortunate to not start aggressively taking advantage > of > > that. In particular we've been held to Java 8 standards for at least 7 > > years. I would advocate we allow and even encourage usage of Java 17 > > features/syntax to help move forward. > > > > The point about backporting is important and I agree the 'easiest' way is > > if changes made to main are backportable. Then again we don't really > need > > everything to be backportable and for sure that will start happening less > > and less. If we're talking about 'bug fixes' then it probably makes > sense > > to prefer for now they avoid Java 17 assuming a given fix should target > > both 2.x and 1.x lines. But if we're talking about new features or even > > improvements I think we should be free to move on to Java 17 > > idioms/benefits. If a contrib does this then it just won't go to the 1.x > > line. This atrophy is natural/ok I think and lets us give the 2.x line > the > > attention/growth it deserves. > > > > Thanks > > > > On Mon, Aug 7, 2023 at 2:19 PM David Handermann < > exceptionfact...@apache.org> > > wrote: > > > > > Mike, > > > > > > Thanks for raising the question. Following Matt's comments, I recommend > > > minimizing use of Java 17 features to make it easier to backport > changes > > > for now. > > > > > > Incremental adjustments can be done when backporting, but it requires > the > > > author and reviewer to pay careful attention since the GitHub automated > > > builds for the main branch run on Java 17. > > > > > > As Matt recommended, the alternative is to provide separate pull > requests > > > for the main and support branches. > > > > > > We already have a few Java 11 and 17 references on the main branch for > > > things like List.of(), and most of these are easy to adjust when > > > backporting, but they do require careful attention. > > > > > > Regards, > > > David Handermann > > > > > > On Mon, Aug 7, 2023 at 4:04 PM Matt Burgess > wrote: > > > > > > > In my opinion that's ok, but I think it would be helpful if a PR is > > > > going to be backported to support/nifi-1.x that the PR author > provides > > > > two PRs, one against main with Java 17 features and one against > > > > support/nifi-1.x with Java 8 features. That being said, allowing Java > > > > 17 features may make maintenance tougher while there's an active 1.x > > > > branch. Maybe we should wait until we only support NiFi 2.x? > > > > > > > > On Mon, Aug 7, 2023 at 4:59 PM Mike Thomsen > > > > wrote: > > > > > > > > > > Since we're standardizing on 17, we're free and clear to use Java > 17 > > > > > features, right? > > > > > > > >
Re: Java 17 features in 2.x
That's a fair point and I think represents the way we want to go forward. If I understand correctly, you're saying bug fixes meant for both lines shouldn't need/use Java 17 features but new capabilities for 2.0 should encourage the use of Java 17 features when prudent? Thanks, Matt On Mon, Aug 7, 2023 at 8:33 PM Joe Witt wrote: > > The views shared thus far are certainly reasonable but I do want to add > a different take. > > The reason we want to do major releases from time to time is so that we can > take advantage of leaps in the language and frameworks we rely on. To that > end it would seem unfortunate to not start aggressively taking advantage of > that. In particular we've been held to Java 8 standards for at least 7 > years. I would advocate we allow and even encourage usage of Java 17 > features/syntax to help move forward. > > The point about backporting is important and I agree the 'easiest' way is > if changes made to main are backportable. Then again we don't really need > everything to be backportable and for sure that will start happening less > and less. If we're talking about 'bug fixes' then it probably makes sense > to prefer for now they avoid Java 17 assuming a given fix should target > both 2.x and 1.x lines. But if we're talking about new features or even > improvements I think we should be free to move on to Java 17 > idioms/benefits. If a contrib does this then it just won't go to the 1.x > line. This atrophy is natural/ok I think and lets us give the 2.x line the > attention/growth it deserves. > > Thanks > > On Mon, Aug 7, 2023 at 2:19 PM David Handermann > wrote: > > > Mike, > > > > Thanks for raising the question. Following Matt's comments, I recommend > > minimizing use of Java 17 features to make it easier to backport changes > > for now. > > > > Incremental adjustments can be done when backporting, but it requires the > > author and reviewer to pay careful attention since the GitHub automated > > builds for the main branch run on Java 17. > > > > As Matt recommended, the alternative is to provide separate pull requests > > for the main and support branches. > > > > We already have a few Java 11 and 17 references on the main branch for > > things like List.of(), and most of these are easy to adjust when > > backporting, but they do require careful attention. > > > > Regards, > > David Handermann > > > > On Mon, Aug 7, 2023 at 4:04 PM Matt Burgess wrote: > > > > > In my opinion that's ok, but I think it would be helpful if a PR is > > > going to be backported to support/nifi-1.x that the PR author provides > > > two PRs, one against main with Java 17 features and one against > > > support/nifi-1.x with Java 8 features. That being said, allowing Java > > > 17 features may make maintenance tougher while there's an active 1.x > > > branch. Maybe we should wait until we only support NiFi 2.x? > > > > > > On Mon, Aug 7, 2023 at 4:59 PM Mike Thomsen > > > wrote: > > > > > > > > Since we're standardizing on 17, we're free and clear to use Java 17 > > > > features, right? > > > > >
Re: Java 17 features in 2.x
The views shared thus far are certainly reasonable but I do want to add a different take. The reason we want to do major releases from time to time is so that we can take advantage of leaps in the language and frameworks we rely on. To that end it would seem unfortunate to not start aggressively taking advantage of that. In particular we've been held to Java 8 standards for at least 7 years. I would advocate we allow and even encourage usage of Java 17 features/syntax to help move forward. The point about backporting is important and I agree the 'easiest' way is if changes made to main are backportable. Then again we don't really need everything to be backportable and for sure that will start happening less and less. If we're talking about 'bug fixes' then it probably makes sense to prefer for now they avoid Java 17 assuming a given fix should target both 2.x and 1.x lines. But if we're talking about new features or even improvements I think we should be free to move on to Java 17 idioms/benefits. If a contrib does this then it just won't go to the 1.x line. This atrophy is natural/ok I think and lets us give the 2.x line the attention/growth it deserves. Thanks On Mon, Aug 7, 2023 at 2:19 PM David Handermann wrote: > Mike, > > Thanks for raising the question. Following Matt's comments, I recommend > minimizing use of Java 17 features to make it easier to backport changes > for now. > > Incremental adjustments can be done when backporting, but it requires the > author and reviewer to pay careful attention since the GitHub automated > builds for the main branch run on Java 17. > > As Matt recommended, the alternative is to provide separate pull requests > for the main and support branches. > > We already have a few Java 11 and 17 references on the main branch for > things like List.of(), and most of these are easy to adjust when > backporting, but they do require careful attention. > > Regards, > David Handermann > > On Mon, Aug 7, 2023 at 4:04 PM Matt Burgess wrote: > > > In my opinion that's ok, but I think it would be helpful if a PR is > > going to be backported to support/nifi-1.x that the PR author provides > > two PRs, one against main with Java 17 features and one against > > support/nifi-1.x with Java 8 features. That being said, allowing Java > > 17 features may make maintenance tougher while there's an active 1.x > > branch. Maybe we should wait until we only support NiFi 2.x? > > > > On Mon, Aug 7, 2023 at 4:59 PM Mike Thomsen > > wrote: > > > > > > Since we're standardizing on 17, we're free and clear to use Java 17 > > > features, right? > > >
Re: Java 17 features in 2.x
Mike, Thanks for raising the question. Following Matt's comments, I recommend minimizing use of Java 17 features to make it easier to backport changes for now. Incremental adjustments can be done when backporting, but it requires the author and reviewer to pay careful attention since the GitHub automated builds for the main branch run on Java 17. As Matt recommended, the alternative is to provide separate pull requests for the main and support branches. We already have a few Java 11 and 17 references on the main branch for things like List.of(), and most of these are easy to adjust when backporting, but they do require careful attention. Regards, David Handermann On Mon, Aug 7, 2023 at 4:04 PM Matt Burgess wrote: > In my opinion that's ok, but I think it would be helpful if a PR is > going to be backported to support/nifi-1.x that the PR author provides > two PRs, one against main with Java 17 features and one against > support/nifi-1.x with Java 8 features. That being said, allowing Java > 17 features may make maintenance tougher while there's an active 1.x > branch. Maybe we should wait until we only support NiFi 2.x? > > On Mon, Aug 7, 2023 at 4:59 PM Mike Thomsen > wrote: > > > > Since we're standardizing on 17, we're free and clear to use Java 17 > > features, right? >
Re: Java 17 features in 2.x
In my opinion that's ok, but I think it would be helpful if a PR is going to be backported to support/nifi-1.x that the PR author provides two PRs, one against main with Java 17 features and one against support/nifi-1.x with Java 8 features. That being said, allowing Java 17 features may make maintenance tougher while there's an active 1.x branch. Maybe we should wait until we only support NiFi 2.x? On Mon, Aug 7, 2023 at 4:59 PM Mike Thomsen wrote: > > Since we're standardizing on 17, we're free and clear to use Java 17 > features, right?
Java 17 features in 2.x
Since we're standardizing on 17, we're free and clear to use Java 17 features, right?
