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 <exceptionfact...@apache.org> 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
