I agree that moving forward with Java 17 as the minimum for NiFi 2.0 is the best approach given the extended lifecycle of support for Java 17.
With the removal of a number of legacy components, the current main branch is in a much better position to make Java 17 the minimum. The deprecation and removal of Nashorn from the JDK is worth highlighting, but it should not be a blocker for moving to Java 17. In this case, NiFi is reflecting the deprecation of Nashorn that already exists in Java 11. I have submitted a PR for NIFI-11630 to mark ECMAScript as deprecated for the support branch in subsequent version 1 releases. With that background, there is ongoing maintenance of the Nashorn engine as an external library, in addition to the GraalVM solution. However, this is a good opportunity to take a different approach to scripting engine integration. For maintenance and security purposes, it would be much better to reduce the number of bundled scripting engines and make it easier to bring your own. The current scripting bundle is around 100 MB, which is a lot of weight for languages and solutions that do not apply across the board. Providing an alternative that makes it easier to bring in a script engine library should provide a better solution for the future. This also should not be a blocker for an initial NiFi 2.0, but it is worth highlighting given the general interest in scripted components. Regards, David Handermann On Thu, Jun 1, 2023, 11:38 PM Dirk Arends <dirk.are...@fontis.com.au> wrote: > Hi Joe, > > > Who will be seriously impacted by the removal of Java 11 and what was > your plan for upgrading to Java 17? > > > > > > thoughts? > > I would support moving the minimum Java version to 17 if it wasn’t for the > fact that Nashorn will be removed. Nashorn is already deprecated in Java > 11, and was then fully removed in Java 15. I understand GraalVM is intended > to be its successor, however this has not yet been integrated into NiFi and > I’ve been unable to satisfactorily integrate it myself to date. > > In my NiFi usage, I make heavy use of the JavaScript engine in > ExecuteScript and InvokeScriptedProcessor processors. To take advantage of > GraalVM supporting later ECMAScript versions than Nashorn, I have been > attempting to use GraalVM as the JavaScript Engine for NiFi with limited > success. > > Further details have been provided in JIRA ticket NIFI-6229 [1] and I’d > welcome any assistance in trying to finalise GraalVM support, but otherwise > I’d consider the loss of Nashorn to be a potential blocker to adopting Java > 17. > > [1] https://issues.apache.org/jira/browse/NIFI-6229 > > > Regards, > > Dirk Arends > > > > On Thu, 1 Jun 2023 at 03:23, Joe Witt <joew...@apache.org> wrote: > > > Team, > > > > We've discussed in the past having NiFi 2.0 move from Java 8 to Java 11 > as > > the required minimum while also working on Java 17. > > > > As we move on in time though we are now 4 months (Sept) from. Java 11 > > openJDK going end of support. Meanwhile, the Spring 5.x line goes end of > > support as of next year and Spring 6.x requires Java 17. Also Java 21 > > comes out in Sept as well and is already the next LTS release. > > > > I am increasingly of the view that we should seriously discuss/consider > > moving to Java 17 as our basis for NiFi 2.0 as otherwise it basically > means > > we'll be forced to move to NiFi 3.0 quite quickly. > > > > We already know we can build and run on Java 17 so we're good there. > We'll > > soon want to do the same for Java 21 ... and the more 'old stuff' we hold > > on to the harder it is. > > > > Who will be seriously impacted by the removal of Java 11 and what was > your > > plan for upgrading to Java 17? > > > > thoughts? > > > > Thanks > > > > > -- > Regards, > > -- > Dirk Arends >
