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, <[email protected]> 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 > <[email protected]> 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, <[email protected]> wrote: > > > > > +1 100% > > > > > > On Wed, Sep 6, 2023 at 11:48 AM Adam Taft <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > 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 < > > > > > > [email protected]> 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 < > > > > [email protected] > > > > > > > > > > > >> 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 > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > > >
