Re: [discuss] nifi 2.0 and Java 21…
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 consideration to having Java 21 > as > > > the > > > > > > basis for nifi 2.x to buy maximum time with LTS alignment. There > > are > > > > > also > > > > > > a couple interesting language features we can likely take > advantage > > > of. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > Thanks > > > > > > Joe > > > > > > > > > > > > On Wed, Jun 21, 2023 at 6:21 AM David Handermann < > > > > > > exceptionfact...@apache.org> wrote: > > > > > > > > > > > >> Hi Dirk, > > > > > >> > > > > > >> Thanks for summarizing your findings in the referenced Jira > > issues. > > > It > > > > > >> sounds like subsequent discussion of Nashorn support may be > better > > > on > > > > a > > > > > new > > > > > >> thread. > > > > > >> > > > > > >> The Spring 6 and Jetty 11 upgrades are going to require > > significant > > > > > work. > > > > > >> One incremental step in that direction was making Java 17 the > > > minimum > > > > > >> version, and upgrading to Jetty 10 should also help move things > > > > forward. > > > > > >> > > > > > >> Although compiling NiFi modules with a reference to the > standalone > > > > > Nashorn > > > > > >> library may introduce issues, there should be other options for > > > > > referencing > > > > > >> the library at runtime. That requires custom class loading, > which > > > some > > > > > >> Processors support, so that seems like the general direction to > > go. > > > > > >> > > > > > >> If you have additional
Re: [discuss] nifi 2.0 and Java 21…
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 consideration to having Java 21 as > > the > > > > > basis for nifi 2.x to buy maximum time with LTS alignment. There > are > > > > also > > > > > a couple interesting language features we can likely take advantage > > of. > > > > > > > > > > What do you think? > > > > > > > > > > Thanks > > > > > Joe > > > > > > > > > > On Wed, Jun 21, 2023 at 6:21 AM David Handermann < > > > > > exceptionfact...@apache.org> wrote: > > > > > > > > > >> Hi Dirk, > > > > >> > > > > >> Thanks for summarizing your findings in the referenced Jira > issues. > > It > > > > >> sounds like subsequent discussion of Nashorn support may be better > > on > > > a > > > > new > > > > >> thread. > > > > >> > > > > >> The Spring 6 and Jetty 11 upgrades are going to require > significant > > > > work. > > > > >> One incremental step in that direction was making Java 17 the > > minimum > > > > >> version, and upgrading to Jetty 10 should also help move things > > > forward. > > > > >> > > > > >> Although compiling NiFi modules with a reference to the standalone > > > > Nashorn > > > > >> library may introduce issues, there should be other options for > > > > referencing > > > > >> the library at runtime. That requires custom class loading, which > > some > > > > >> Processors support, so that seems like the general direction to > go. > > > > >> > > > > >> If you have additional findings, feel free to start a new > developer > > > list > > > > >> thread and that may gather additional feedback. > > > > >> > > > > >> Regards, > > > > >> David Handermann > > > > >> > > > > >> On Wed, Jun 21, 2023 at 12:17 AM Dirk Arends < > > > dirk.are...@fontis.com.au > > > > > > > > > >> wrote: > > > > >> > > > > >>> Since initially raising concerns about the move to Java 17 losing > > > > >> Nashorn, > > > > >>> I have been investigating the suggestion to use Nashorn as a > > > standalone > > > > >>> package as potential easier alternative to GraalVM. [1] > > > > >>> > > > > >>> While
Re: [discuss] nifi 2.0 and Java 21…
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 consideration to having Java 21 as > the > > > > basis for nifi 2.x to buy maximum time with LTS alignment. There are > > > also > > > > a couple interesting language features we can likely take advantage > of. > > > > > > > > What do you think? > > > > > > > > Thanks > > > > Joe > > > > > > > > On Wed, Jun 21, 2023 at 6:21 AM David Handermann < > > > > exceptionfact...@apache.org> wrote: > > > > > > > >> Hi Dirk, > > > >> > > > >> Thanks for summarizing your findings in the referenced Jira issues. > It > > > >> sounds like subsequent discussion of Nashorn support may be better > on > > a > > > new > > > >> thread. > > > >> > > > >> The Spring 6 and Jetty 11 upgrades are going to require significant > > > work. > > > >> One incremental step in that direction was making Java 17 the > minimum > > > >> version, and upgrading to Jetty 10 should also help move things > > forward. > > > >> > > > >> Although compiling NiFi modules with a reference to the standalone > > > Nashorn > > > >> library may introduce issues, there should be other options for > > > referencing > > > >> the library at runtime. That requires custom class loading, which > some > > > >> Processors support, so that seems like the general direction to go. > > > >> > > > >> If you have additional findings, feel free to start a new developer > > list > > > >> thread and that may gather additional feedback. > > > >> > > > >> Regards, > > > >> David Handermann > > > >> > > > >> On Wed, Jun 21, 2023 at 12:17 AM Dirk Arends < > > dirk.are...@fontis.com.au > > > > > > > >> wrote: > > > >> > > > >>> Since initially raising concerns about the move to Java 17 losing > > > >> Nashorn, > > > >>> I have been investigating the suggestion to use Nashorn as a > > standalone > > > >>> package as potential easier alternative to GraalVM. [1] > > > >>> > > > >>> While making some progress, a number of issues have been > encountered > > > >> which > > > >>> I haven't been able to resolve as yet. More details are included in > > > >>> relevant JIRA tickets, but summarising: > > > >>> > > > >>> - Building NiFi with a recent Nashorn dependency leads to errors > > > >>> "Unsupported class file major version 61" [2] > > > >>> - Building NiFi using Java 17 highlights issues with the current > > Jetty > > > >>> version, which I believe would require an upgrade from 9.4.51 to > > > 11.0.15 > > > >>> [3] > > > >>> - Jetty 11 then requires an upgrade of the Spring Framework > version 5 > > > to > > > >> 6. > > > >>> [4] > > > >>> > > > >>> The current steps to remove references to "Javascript" as a > > > preinstalled > > > >>> scripting language [5] are understandable, but it does seem there > is > > > >> still > > > >>> quite a bit to do before Nashorn or another external scripting > engine > > > >> could > > > >>> be used. > > > >>> > > > >>> [1]
Re: [discuss] nifi 2.0 and Java 21…
+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 consideration to having Java 21 as the > > > basis for nifi 2.x to buy maximum time with LTS alignment. There are > > also > > > a couple interesting language features we can likely take advantage of. > > > > > > What do you think? > > > > > > Thanks > > > Joe > > > > > > On Wed, Jun 21, 2023 at 6:21 AM David Handermann < > > > exceptionfact...@apache.org> wrote: > > > > > >> Hi Dirk, > > >> > > >> Thanks for summarizing your findings in the referenced Jira issues. It > > >> sounds like subsequent discussion of Nashorn support may be better on > a > > new > > >> thread. > > >> > > >> The Spring 6 and Jetty 11 upgrades are going to require significant > > work. > > >> One incremental step in that direction was making Java 17 the minimum > > >> version, and upgrading to Jetty 10 should also help move things > forward. > > >> > > >> Although compiling NiFi modules with a reference to the standalone > > Nashorn > > >> library may introduce issues, there should be other options for > > referencing > > >> the library at runtime. That requires custom class loading, which some > > >> Processors support, so that seems like the general direction to go. > > >> > > >> If you have additional findings, feel free to start a new developer > list > > >> thread and that may gather additional feedback. > > >> > > >> Regards, > > >> David Handermann > > >> > > >> On Wed, Jun 21, 2023 at 12:17 AM Dirk Arends < > dirk.are...@fontis.com.au > > > > > >> wrote: > > >> > > >>> Since initially raising concerns about the move to Java 17 losing > > >> Nashorn, > > >>> I have been investigating the suggestion to use Nashorn as a > standalone > > >>> package as potential easier alternative to GraalVM. [1] > > >>> > > >>> While making some progress, a number of issues have been encountered > > >> which > > >>> I haven't been able to resolve as yet. More details are included in > > >>> relevant JIRA tickets, but summarising: > > >>> > > >>> - Building NiFi with a recent Nashorn dependency leads to errors > > >>> "Unsupported class file major version 61" [2] > > >>> - Building NiFi using Java 17 highlights issues with the current > Jetty > > >>> version, which I believe would require an upgrade from 9.4.51 to > > 11.0.15 > > >>> [3] > > >>> - Jetty 11 then requires an upgrade of the Spring Framework version 5 > > to > > >> 6. > > >>> [4] > > >>> > > >>> The current steps to remove references to "Javascript" as a > > preinstalled > > >>> scripting language [5] are understandable, but it does seem there is > > >> still > > >>> quite a bit to do before Nashorn or another external scripting engine > > >> could > > >>> be used. > > >>> > > >>> [1] https://issues.apache.org/jira/browse/NIFI-11700: Java 17 > Nashorn > > >>> standalone support > > >>> [2] https://issues.apache.org/jira/browse/NIFI-11701: Support > building > > >>> with > > >>> version 61 class files > > >>> [3] https://issues.apache.org/jira/browse/NIFI-11702: Upgrade Jetty > to > > >>> version 11 > > >>> [4] https://issues.apache.org/jira/browse/NIFI-11703: Upgrade Spring > > >>> Framework to version 6 > > >>> [5] https://issues.apache.org/jira/browse/NIFI-11713: Remove > > Deprecated > > >>> ECMAScript Support > > >>> > > >>> Regards, > > >>> Dirk Arends > > >>> > > >> > > > > >
Re: [discuss] nifi 2.0 and Java 21…
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 consideration to having Java 21 as the > > basis for nifi 2.x to buy maximum time with LTS alignment. There are > also > > a couple interesting language features we can likely take advantage of. > > > > What do you think? > > > > Thanks > > Joe > > > > On Wed, Jun 21, 2023 at 6:21 AM David Handermann < > > exceptionfact...@apache.org> wrote: > > > >> Hi Dirk, > >> > >> Thanks for summarizing your findings in the referenced Jira issues. It > >> sounds like subsequent discussion of Nashorn support may be better on a > new > >> thread. > >> > >> The Spring 6 and Jetty 11 upgrades are going to require significant > work. > >> One incremental step in that direction was making Java 17 the minimum > >> version, and upgrading to Jetty 10 should also help move things forward. > >> > >> Although compiling NiFi modules with a reference to the standalone > Nashorn > >> library may introduce issues, there should be other options for > referencing > >> the library at runtime. That requires custom class loading, which some > >> Processors support, so that seems like the general direction to go. > >> > >> If you have additional findings, feel free to start a new developer list > >> thread and that may gather additional feedback. > >> > >> Regards, > >> David Handermann > >> > >> On Wed, Jun 21, 2023 at 12:17 AM Dirk Arends > > >> wrote: > >> > >>> Since initially raising concerns about the move to Java 17 losing > >> Nashorn, > >>> I have been investigating the suggestion to use Nashorn as a standalone > >>> package as potential easier alternative to GraalVM. [1] > >>> > >>> While making some progress, a number of issues have been encountered > >> which > >>> I haven't been able to resolve as yet. More details are included in > >>> relevant JIRA tickets, but summarising: > >>> > >>> - Building NiFi with a recent Nashorn dependency leads to errors > >>> "Unsupported class file major version 61" [2] > >>> - Building NiFi using Java 17 highlights issues with the current Jetty > >>> version, which I believe would require an upgrade from 9.4.51 to > 11.0.15 > >>> [3] > >>> - Jetty 11 then requires an upgrade of the Spring Framework version 5 > to > >> 6. > >>> [4] > >>> > >>> The current steps to remove references to "Javascript" as a > preinstalled > >>> scripting language [5] are understandable, but it does seem there is > >> still > >>> quite a bit to do before Nashorn or another external scripting engine > >> could > >>> be used. > >>> > >>> [1] https://issues.apache.org/jira/browse/NIFI-11700: Java 17 Nashorn > >>> standalone support > >>> [2] https://issues.apache.org/jira/browse/NIFI-11701: Support building > >>> with > >>> version 61 class files > >>> [3] https://issues.apache.org/jira/browse/NIFI-11702: Upgrade Jetty to > >>> version 11 > >>> [4] https://issues.apache.org/jira/browse/NIFI-11703: Upgrade Spring > >>> Framework to version 6 > >>> [5] https://issues.apache.org/jira/browse/NIFI-11713: Remove > Deprecated > >>> ECMAScript Support > >>> > >>> Regards, > >>> Dirk Arends > >>> > >> > >
Re: [discuss] nifi 2.0 and Java 21…
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 consideration to having Java 21 as the > basis for nifi 2.x to buy maximum time with LTS alignment. There are also > a couple interesting language features we can likely take advantage of. > > What do you think? > > Thanks > Joe > > On Wed, Jun 21, 2023 at 6:21 AM David Handermann < > exceptionfact...@apache.org> wrote: > >> Hi Dirk, >> >> Thanks for summarizing your findings in the referenced Jira issues. It >> sounds like subsequent discussion of Nashorn support may be better on a new >> thread. >> >> The Spring 6 and Jetty 11 upgrades are going to require significant work. >> One incremental step in that direction was making Java 17 the minimum >> version, and upgrading to Jetty 10 should also help move things forward. >> >> Although compiling NiFi modules with a reference to the standalone Nashorn >> library may introduce issues, there should be other options for referencing >> the library at runtime. That requires custom class loading, which some >> Processors support, so that seems like the general direction to go. >> >> If you have additional findings, feel free to start a new developer list >> thread and that may gather additional feedback. >> >> Regards, >> David Handermann >> >> On Wed, Jun 21, 2023 at 12:17 AM Dirk Arends >> wrote: >> >>> Since initially raising concerns about the move to Java 17 losing >> Nashorn, >>> I have been investigating the suggestion to use Nashorn as a standalone >>> package as potential easier alternative to GraalVM. [1] >>> >>> While making some progress, a number of issues have been encountered >> which >>> I haven't been able to resolve as yet. More details are included in >>> relevant JIRA tickets, but summarising: >>> >>> - Building NiFi with a recent Nashorn dependency leads to errors >>> "Unsupported class file major version 61" [2] >>> - Building NiFi using Java 17 highlights issues with the current Jetty >>> version, which I believe would require an upgrade from 9.4.51 to 11.0.15 >>> [3] >>> - Jetty 11 then requires an upgrade of the Spring Framework version 5 to >> 6. >>> [4] >>> >>> The current steps to remove references to "Javascript" as a preinstalled >>> scripting language [5] are understandable, but it does seem there is >> still >>> quite a bit to do before Nashorn or another external scripting engine >> could >>> be used. >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-11700: Java 17 Nashorn >>> standalone support >>> [2] https://issues.apache.org/jira/browse/NIFI-11701: Support building >>> with >>> version 61 class files >>> [3] https://issues.apache.org/jira/browse/NIFI-11702: Upgrade Jetty to >>> version 11 >>> [4] https://issues.apache.org/jira/browse/NIFI-11703: Upgrade Spring >>> Framework to version 6 >>> [5] https://issues.apache.org/jira/browse/NIFI-11713: Remove Deprecated >>> ECMAScript Support >>> >>> Regards, >>> Dirk Arends >>> >>
Re: [discuss] nifi 2.0 and Java 21…
Team Thought it might be worth relighting this thread with Java 21 GA imminent. Given the timing we should give consideration to having Java 21 as the basis for nifi 2.x to buy maximum time with LTS alignment. There are also a couple interesting language features we can likely take advantage of. What do you think? Thanks Joe On Wed, Jun 21, 2023 at 6:21 AM David Handermann < exceptionfact...@apache.org> wrote: > Hi Dirk, > > Thanks for summarizing your findings in the referenced Jira issues. It > sounds like subsequent discussion of Nashorn support may be better on a new > thread. > > The Spring 6 and Jetty 11 upgrades are going to require significant work. > One incremental step in that direction was making Java 17 the minimum > version, and upgrading to Jetty 10 should also help move things forward. > > Although compiling NiFi modules with a reference to the standalone Nashorn > library may introduce issues, there should be other options for referencing > the library at runtime. That requires custom class loading, which some > Processors support, so that seems like the general direction to go. > > If you have additional findings, feel free to start a new developer list > thread and that may gather additional feedback. > > Regards, > David Handermann > > On Wed, Jun 21, 2023 at 12:17 AM Dirk Arends > wrote: > > > Since initially raising concerns about the move to Java 17 losing > Nashorn, > > I have been investigating the suggestion to use Nashorn as a standalone > > package as potential easier alternative to GraalVM. [1] > > > > While making some progress, a number of issues have been encountered > which > > I haven't been able to resolve as yet. More details are included in > > relevant JIRA tickets, but summarising: > > > > - Building NiFi with a recent Nashorn dependency leads to errors > > "Unsupported class file major version 61" [2] > > - Building NiFi using Java 17 highlights issues with the current Jetty > > version, which I believe would require an upgrade from 9.4.51 to 11.0.15 > > [3] > > - Jetty 11 then requires an upgrade of the Spring Framework version 5 to > 6. > > [4] > > > > The current steps to remove references to "Javascript" as a preinstalled > > scripting language [5] are understandable, but it does seem there is > still > > quite a bit to do before Nashorn or another external scripting engine > could > > be used. > > > > [1] https://issues.apache.org/jira/browse/NIFI-11700: Java 17 Nashorn > > standalone support > > [2] https://issues.apache.org/jira/browse/NIFI-11701: Support building > > with > > version 61 class files > > [3] https://issues.apache.org/jira/browse/NIFI-11702: Upgrade Jetty to > > version 11 > > [4] https://issues.apache.org/jira/browse/NIFI-11703: Upgrade Spring > > Framework to version 6 > > [5] https://issues.apache.org/jira/browse/NIFI-11713: Remove Deprecated > > ECMAScript Support > > > > Regards, > > Dirk Arends > > >
