Re: [discuss] nifi 2.0 and Java 21…
Pierre A few concerns you raised so want to address my view on each: Will users be able to adopt Java 21 fast enough? I share Brandon's view on that in terms of their adoption timeline. It will likely align well with NiFi 2.0 itself in my estimation. Will this delay NiFi 2.0? If it would then I'd not be supportive. I don't think we need to bother with adopting any of the features now. What I would like us to have is the option to adopt them as we progress. We should get 2.0 done asap and if this added delay then I'd be way less interested in this idea. Feature benefits of 21 and what will that bring? Mark spoke well to the key one that stood out to me which was the new threading model available. It would be awfully nice to leverage that for the efficiency it represents and especially if it can reduce some of our heap usage which is valuable in cloud/shared compute contexts. Performance benefits of Java 21? It appears from some analysis found with googling that Java 21 brings out of the box 4-5% performance increases generally. Not amazing but useful. User experience otherwise with Java 21? I believe it would be consistent with Java 17 for their point of view in terms of install/config/etc.. My motivation for this is fairly pure honestly. Since we're setting our new minimum bar that lives for as long as the 2.x release line lives I'd like to set it at the current LTS available when we ship that line as well. Thanks On Thu, Sep 7, 2023 at 4:22 AM Brandon DeVries wrote: > +1 to requiring java 21. Starting off as "up to date" as possibly makes a > lot of sense, and some of the new features seem especially relevant to NiFi. > > I definitely understand the concerns about organizations being willing / > able to approve Java 21... But those same organizations might also be > hesitant to move to NiFi 2.0. We will continue to support java 17 & NiFi > 1.x for some time, so hopefully those groups will have the time they need > to get approvals, do evaluations, and upgrade. > > Brandon > > From: Pierre Villard > Sent: Thursday, September 7, 2023 6:15:58 AM > To: dev@nifi.apache.org > Subject: Re: [discuss] nifi 2.0 and Java 21… > > Hi all, > > I share the concerns raised by Chris regarding how quickly users of NiFi > will be able to adopt Java 21. > > While I'm definitely in favor of using the latest and greatest, especially > when it brings to the table such significant features, we need to be > careful as it may significantly delay the adoption of NiFi 2.0 in big > companies where deploying Java 21 will take time. I acknowledge that going > from Java 8 to Java 17 is certainly the same effort as going from Java 8 to > Java 21 but how quickly security-sensitive environments will adopt a new > release of Java that is completely new? > > In addition to that, it sounds like we would add a significant rework of > the framework in NiFi 2.0 assuming we adopt Java 21 as the minimum version. > Do we think this is going to significantly delay the first release of NiFi > 2.0? We still have work to do but adding this on top could delay the > release, no? > > Finally, the features that Java 21 are bringing sound super interesting in > the context of NiFi but do we already have an idea of what it will improve? > is it the user experience, and if so, how will it change? is it the > performance, and if so, do we have an idea of how things will improve? > > Thanks, > Pierre > > Le mer. 6 sept. 2023 à 23:07, Chris Sampson > a écrit : > > > Yeah, I understand the need to move to 21 as a minimum to take advantage > of > > its features. Hopefully the wider java ecosystem won't be an issue in the > > short term. > > > > I just wanted the discussion to be clear about this being a change to the > > Java baseline/minimum for NiFi 2.0. > > > > It's a +1 from me. > > > > On Wed, 6 Sept 2023, 19:01 Joe Witt, wrote: > > > > > Chris > > > > > > My suggestion is rooted in making Java 21 the minimum of the NiFi 2.0 > > > line. It would not work on Java 17. The reason for this is so that we > > can > > > leverage the longest duration of a given LTS line while also benefiting > > > from the language improvements that affords. Maintaining compatibility > > > with future versions we generally have to do. But whatever the minimum > > > version we accept dictates which language features we can leverage. So > > if > > > it is 17 then we can't leverage anything from the 21 line for example. > > > > > > GIven the nature and timelines of LTS I don't really think there is the > > > same burn in logic that we'd have all known in the past before the > > > LTS/STS/etc.. release constructs existed. > > > > > > Thanks > > > > > > On Wed, Sep 6, 2023 at 10:53 AM Chris Sampson > > > wrote: > > > > > > > To be clear, is the discussion one of making Java 21 the minimum > > > > requirement for NiFi 2.0.0, or rather NiFi 2.x be compatible with > Java > > > 21, > > > > while retaining Java 17 as a minimum? >
Re: NIFI Jira ticket not updated with link to NIFI PR code in Github
Dan, That happens sometimes, it can take a while for the link to be added to the Jira, but usually it does happen eventually. Sometimes I'll add the link manually then remove it when the system catches up and adds the link to the Jira. Regards, Matt On Thu, Sep 7, 2023 at 10:49 AM Dan S wrote: > > I recently submitted a PR for > https://issues.apache.org/jira/browse/NIFI-11197 at > https://github.com/apache/nifi/pull/7665 but the Jira ticket has not been > updated with the link to the PR as it usually is. Please advise. Thanks!
NIFI Jira ticket not updated with link to NIFI PR code in Github
I recently submitted a PR for https://issues.apache.org/jira/browse/NIFI-11197 at https://github.com/apache/nifi/pull/7665 but the Jira ticket has not been updated with the link to the PR as it usually is. Please advise. Thanks!
Re: Feature Request - Selection box
Hey Jøran, This is possible today. Just simply hold shift while you click & drag. Thanks -Mark > On Sep 7, 2023, at 3:25 AM, Jøran Henriksen > wrote: > > Hey > > I would like to propose a new feature when dealing with canvas interface > mouse I/O events: > IMHO, it would be a lot better if we had the possibility to drag/create a > selection box when selecting multiple nifi components, instead of just having > the possibility to shift-click to do multiple components select. > > I would propose the following mouse key mappings: > > Right click -> Context-Menu (same as today) > Right drag -> Move canvas (currently on left drag) > Left click -> Select component (same as today) > Left drag -> [New feature] Selection box > Scroll drag-> Move canvas > > > Best, Jøran
Feature Request - Selection box
Hey I would like to propose a new feature when dealing with canvas interface mouse I/O events: IMHO, it would be a lot better if we had the possibility to drag/create a selection box when selecting multiple nifi components, instead of just having the possibility to shift-click to do multiple components select. I would propose the following mouse key mappings: Right click -> Context-Menu (same as today) Right drag -> Move canvas (currently on left drag) Left click -> Select component (same as today) Left drag -> [New feature] Selection box Scroll drag-> Move canvas Best, Jøran
Re: [discuss] nifi 2.0 and Java 21…
+1 to requiring java 21. Starting off as "up to date" as possibly makes a lot of sense, and some of the new features seem especially relevant to NiFi. I definitely understand the concerns about organizations being willing / able to approve Java 21... But those same organizations might also be hesitant to move to NiFi 2.0. We will continue to support java 17 & NiFi 1.x for some time, so hopefully those groups will have the time they need to get approvals, do evaluations, and upgrade. Brandon From: Pierre Villard Sent: Thursday, September 7, 2023 6:15:58 AM To: dev@nifi.apache.org Subject: Re: [discuss] nifi 2.0 and Java 21… Hi all, I share the concerns raised by Chris regarding how quickly users of NiFi will be able to adopt Java 21. While I'm definitely in favor of using the latest and greatest, especially when it brings to the table such significant features, we need to be careful as it may significantly delay the adoption of NiFi 2.0 in big companies where deploying Java 21 will take time. I acknowledge that going from Java 8 to Java 17 is certainly the same effort as going from Java 8 to Java 21 but how quickly security-sensitive environments will adopt a new release of Java that is completely new? In addition to that, it sounds like we would add a significant rework of the framework in NiFi 2.0 assuming we adopt Java 21 as the minimum version. Do we think this is going to significantly delay the first release of NiFi 2.0? We still have work to do but adding this on top could delay the release, no? Finally, the features that Java 21 are bringing sound super interesting in the context of NiFi but do we already have an idea of what it will improve? is it the user experience, and if so, how will it change? is it the performance, and if so, do we have an idea of how things will improve? Thanks, Pierre Le mer. 6 sept. 2023 à 23:07, Chris Sampson a écrit : > Yeah, I understand the need to move to 21 as a minimum to take advantage of > its features. Hopefully the wider java ecosystem won't be an issue in the > short term. > > I just wanted the discussion to be clear about this being a change to the > Java baseline/minimum for NiFi 2.0. > > It's a +1 from me. > > On Wed, 6 Sept 2023, 19:01 Joe Witt, wrote: > > > Chris > > > > My suggestion is rooted in making Java 21 the minimum of the NiFi 2.0 > > line. It would not work on Java 17. The reason for this is so that we > can > > leverage the longest duration of a given LTS line while also benefiting > > from the language improvements that affords. Maintaining compatibility > > with future versions we generally have to do. But whatever the minimum > > version we accept dictates which language features we can leverage. So > if > > it is 17 then we can't leverage anything from the 21 line for example. > > > > GIven the nature and timelines of LTS I don't really think there is the > > same burn in logic that we'd have all known in the past before the > > LTS/STS/etc.. release constructs existed. > > > > Thanks > > > > On Wed, Sep 6, 2023 at 10:53 AM Chris Sampson > > wrote: > > > > > To be clear, is the discussion one of making Java 21 the minimum > > > requirement for NiFi 2.0.0, or rather NiFi 2.x be compatible with Java > > 21, > > > while retaining Java 17 as a minimum? > > > > > > If we moved straight to a Java 21 requirement, will we run into > > > compatibility issues that delay initial NiFi 2 release? Will the move > to > > > Java 21 mean some organisations delay their migration to NiFi 2 through > > not > > > wanting to move to the latest Java LTS version until it's had a time > for > > > "settling" through security/bug patches, etc.? And are either of these > > > sufficient concern to pause Java 21 becoming the requirement, as we may > > > then need to extend NiFi 1.x maintenance for longer into the future? > > > > > > Generally, I'm in favour of moving to "latest and greatest", > particularly > > > for LTS versions of technologies, but the rate of Java version adoption > > > across the community gives me pause. > > > > > > I certainly see the advantage of new Java features for NiFi in Java 21, > > > such as the already mentioned virtual threads. > > > > > > On Wed, 6 Sept 2023, 18:34 Mike Thomsen, > wrote: > > > > > > > +1 100% > > > > > > > > On Wed, Sep 6, 2023 at 11:48 AM Adam Taft wrote: > > > > > > > > > Yes, please. +1 Exactly what Mark said. Virtual threads have > > potential > > > to > > > > > be extremely impactful to applications like NiFi. > > > > > > > > > > /Adam > > > > > > > > > > On Wed, Sep 6, 2023 at 7:26 AM Mark Payne > > > wrote: > > > > > > > > > > > Thanks for bringing his up, Joe. > > > > > > > > > > > > I would definitely be a +1. I think the new virtual thread > concept > > > > would > > > > > > have great impact on us. > > > > > > It would allow us to significantly simplify our scheduling logic, > > > which > > > > > > would help with code maintainability > > > > > >
Re: [discuss] nifi 2.0 and Java 21…
Hi all, I share the concerns raised by Chris regarding how quickly users of NiFi will be able to adopt Java 21. While I'm definitely in favor of using the latest and greatest, especially when it brings to the table such significant features, we need to be careful as it may significantly delay the adoption of NiFi 2.0 in big companies where deploying Java 21 will take time. I acknowledge that going from Java 8 to Java 17 is certainly the same effort as going from Java 8 to Java 21 but how quickly security-sensitive environments will adopt a new release of Java that is completely new? In addition to that, it sounds like we would add a significant rework of the framework in NiFi 2.0 assuming we adopt Java 21 as the minimum version. Do we think this is going to significantly delay the first release of NiFi 2.0? We still have work to do but adding this on top could delay the release, no? Finally, the features that Java 21 are bringing sound super interesting in the context of NiFi but do we already have an idea of what it will improve? is it the user experience, and if so, how will it change? is it the performance, and if so, do we have an idea of how things will improve? Thanks, Pierre Le mer. 6 sept. 2023 à 23:07, Chris Sampson a écrit : > Yeah, I understand the need to move to 21 as a minimum to take advantage of > its features. Hopefully the wider java ecosystem won't be an issue in the > short term. > > I just wanted the discussion to be clear about this being a change to the > Java baseline/minimum for NiFi 2.0. > > It's a +1 from me. > > On Wed, 6 Sept 2023, 19:01 Joe Witt, wrote: > > > Chris > > > > My suggestion is rooted in making Java 21 the minimum of the NiFi 2.0 > > line. It would not work on Java 17. The reason for this is so that we > can > > leverage the longest duration of a given LTS line while also benefiting > > from the language improvements that affords. Maintaining compatibility > > with future versions we generally have to do. But whatever the minimum > > version we accept dictates which language features we can leverage. So > if > > it is 17 then we can't leverage anything from the 21 line for example. > > > > GIven the nature and timelines of LTS I don't really think there is the > > same burn in logic that we'd have all known in the past before the > > LTS/STS/etc.. release constructs existed. > > > > Thanks > > > > On Wed, Sep 6, 2023 at 10:53 AM Chris Sampson > > wrote: > > > > > To be clear, is the discussion one of making Java 21 the minimum > > > requirement for NiFi 2.0.0, or rather NiFi 2.x be compatible with Java > > 21, > > > while retaining Java 17 as a minimum? > > > > > > If we moved straight to a Java 21 requirement, will we run into > > > compatibility issues that delay initial NiFi 2 release? Will the move > to > > > Java 21 mean some organisations delay their migration to NiFi 2 through > > not > > > wanting to move to the latest Java LTS version until it's had a time > for > > > "settling" through security/bug patches, etc.? And are either of these > > > sufficient concern to pause Java 21 becoming the requirement, as we may > > > then need to extend NiFi 1.x maintenance for longer into the future? > > > > > > Generally, I'm in favour of moving to "latest and greatest", > particularly > > > for LTS versions of technologies, but the rate of Java version adoption > > > across the community gives me pause. > > > > > > I certainly see the advantage of new Java features for NiFi in Java 21, > > > such as the already mentioned virtual threads. > > > > > > On Wed, 6 Sept 2023, 18:34 Mike Thomsen, > wrote: > > > > > > > +1 100% > > > > > > > > On Wed, Sep 6, 2023 at 11:48 AM Adam Taft wrote: > > > > > > > > > Yes, please. +1 Exactly what Mark said. Virtual threads have > > potential > > > to > > > > > be extremely impactful to applications like NiFi. > > > > > > > > > > /Adam > > > > > > > > > > On Wed, Sep 6, 2023 at 7:26 AM Mark Payne > > > wrote: > > > > > > > > > > > Thanks for bringing his up, Joe. > > > > > > > > > > > > I would definitely be a +1. I think the new virtual thread > concept > > > > would > > > > > > have great impact on us. > > > > > > It would allow us to significantly simplify our scheduling logic, > > > which > > > > > > would help with code maintainability > > > > > > but would also make configuration simpler. This is one of the > most > > > > > > difficult things for users to configure, > > > > > > and I would very much welcome the ability to simplify this. It > > would > > > > > > likely also yield better off-heap memory > > > > > > utilization by reducing the number of native threads necessary. > > > > > > > > > > > > Thanks > > > > > > -Mark > > > > > > > > > > > > > > > > > > > On Sep 6, 2023, at 10:20 AM, Joe Witt > > wrote: > > > > > > > > > > > > > > Team > > > > > > > > > > > > > > Thought it might be worth relighting this thread with Java 21 > GA > > > > > > imminent. > > > > > > > Given the timing we should give
