I would be extremely careful about moving to Java 11 -- especially if NiFi 1.x is not actively maintained. I am sure it's not news to anyone, but a lot (most?) of people are still on Java 8, for better or worse, and I do not think moving without a strong, compelling reason is advisable. It's not as simple to tell users to just update Java -- there is a lot involved with that.
This is from last year, but probably still proves the point: https://www.jetbrains.com/lp/devecosystem-2020/java/ On Fri, Jul 23, 2021 at 10:32 AM Joe Witt <[email protected]> wrote: > David, > > I think this is a highly reasonable approach and such a focus will > greatly help make a 2.0 release far more approachable to knock out. > Not only that but tech debt reduction would help make work towards > major features we'd think about in a 'major release' sense more > approachable. > > We should remove all deprecated things (as well as verify we have the > right list). We should remove/consider removal of deprecated concepts > like templates. We should consider whether we can resolve the various > ways we've handled what are now parameters down to one clean approach. > We should remove options in the nifi.properties which turn out to > never be used quite right (if there are). There is quite a bit we can > do purely in the name of tech debt reduction. > > Lots to consider here but I think this is the right discussion. > > Than ks > > On Fri, Jul 23, 2021 at 7:26 AM Bryan Bende <[email protected]> wrote: > > > > I'm a +1 for this... Not sure if this falls under "Removing Deprecated > > Components", but I think we should also look at anything that has been > > marked as deprecated throughout the code base as a candidate for > > removal. There are quite a few classes, methods, properties, etc that > > have been waiting for a chance to be removed. > > > > On Fri, Jul 23, 2021 at 10:13 AM David Handermann > > <[email protected]> wrote: > > > > > > Team, > > > > > > With all of the excellent work that many have contributed to NiFi over > the > > > years, the code base has also accumulated some amount of technical > debt. A > > > handful of components have been marked as deprecated, and some > components > > > remain in the code base to support integration with old versions of > various > > > products. Following the principles of semantic versioning, introducing > a > > > major release would provide the opportunity to remove these deprecated > and > > > unsupported components. > > > > > > Rather than focusing the next major release on new features, what do > you > > > think about focusing on technical debt removal? This approach would not > > > make for the most interesting release, but it provides the opportunity > to > > > clean up elements that involve breaking changes. > > > > > > Focusing on technical debt, at least three primary goals come to mind > for > > > the next major release: > > > > > > 1. Removal of deprecated and unmaintained components > > > 2. Require Java 11 as the minimum supported version > > > 3. Transition internal date and time handling to JSR 310 java.time > > > components > > > > > > *Removing Deprecated Components* > > > > > > Removing support for older and deprecated components provides a great > > > opportunity to improve the overall security posture when it comes to > > > maintaining dependencies. The OWASP dependency plugin report currently > > > generates 50 MB of HTML for questionable dependencies, many of which > are > > > related to old versions of various libraries. > > > > > > As a starting point, here are a handful of components and extension > modules > > > that could be targeted for removal in a major version: > > > > > > - PostHTTP and GetHTTP > > > - ListenLumberjack and the entire nifi-lumberjack-bundle > > > - ListenBeats and the entire nifi-beats-bundle > > > - Elasticsearch 5 components > > > - Hive 1 and 2 components > > > > > > *Requiring Java 11* > > > > > > Java 8 is now over seven years old, and NiFi has supported general > > > compatibility with Java 11 for several years. NiFi 1.14.0 incorporated > > > internal improvements specifically related to TLS 1.3, which allowed > > > closing out the long-running Java 11 compatibility epic NIFI-5174. > Making > > > Java 11 the minimum required version provides the opportunity to > address > > > any lingering edge cases and put NiFi in a better position to support > > > current Java versions. > > > > > > *JSR 310 for Date and Time Handling* > > > > > > Without making the scope too broad, transitioning internal date and > time > > > handling to use DateTimeFormatter instead of SimpleDateFormat would > provide > > > a number of advantages. The Java Time components provide much better > > > clarity when it comes to handling localized date and time > representations, > > > and also avoid the inherent confusion of java.sql.Date extending > > > java.util.Date. Many internal components, specifically Record-oriented > > > processors and services, rely on date parsing, leading to confusion and > > > various workarounds. The pattern formats of SimpleDateFormat and > > > DateTimeFormatter are very similar, but there are a few subtle > differences. > > > Making this transition would provide a much better foundation going > forward. > > > > > > *Conclusion* > > > > > > Thanks for giving this proposal some consideration. Many of you have > been > > > developing NiFi for years and I look forward to your feedback. I would > be > > > glad to put together a more formalized recommendation on Confluence and > > > write up Jira epics if this general approach sounds agreeable to the > > > community. > > > > > > Regards, > > > David Handermann >
