Sl4j is kind'a the standard now for logging in Java, I've been using it since 2008 in both open source and on the job.
Its an abstraction over all the java logging frameworks out there, so something like slf4j - log4j2 would be an option to consider; we can then do away with present LogUtils :) On Mon, Jul 18, 2016 at 11:03 AM, Ellison Anne Williams < [email protected]> wrote: > Unless someone objects, I will create a JIRA issue for upgrading to Java 8 > and another for upgrading to log4j2. > > It seems that the jury is still out on using Slf4j -- I will mention it in > the issue for log4j2. > > On Mon, Jul 18, 2016 at 6:30 AM, Tim Ellison <[email protected]> > wrote: > > > On 17/07/16 18:29, Joe Witt wrote: > > > I would recommend at this stage to consider Java 8 as the basis. In > > > NiFi our upcoming major release establishes java 8 as the baseline. I > > > believe the community went that route because: > > > > > > - It contains language features that are beneficial and that > > > developers wanted to use. > > > > > > - It can make it easier to accept PRs as you may find contributors > > > wanting to use those features so could be important for community > > > growth > > > > > > - Some popular dependency libraries have moved to Java 8 > > > > > > - Java 7 is EOL (https://java.com/en/download/faq/java_7.xml) > > > > I agree. Unless any of Pirk's dependencies refuse to work with Java 8 > > then moving to the latest supported version of Java makes sense for all > > the good reasons Joe has listed (and I'll add "improved performance" as > > another). > > > > > As for coding standards I suspect there are projects that have taken a > > > stronger stance on this than we have in NiFi. But, the checkstyle > > > configuration we have seems to work out pretty well and is largely > > > based on Java standards plus what Accumulo had. So, you might want to > > > look around a bit to find a style that works well. > > > > While not really to my taste, it is good to see a consistent standard > > applied. This really is up to committers to agree upon one and stick > > with it. Having the tooling support is makes it trivial. > > > > > As for preferred IDE - Good luck with that! I'm definitely in favor > > > of avoiding having an opinion here. By integrating things like > > > checkstyle, using Maven, and using Git then much of the need to have a > > > preference is eliminated in my experience. NiFi has have folks using > > > Eclipse, IntelliJ (admittedly seems to be the favorite), and Netbeans > > > (ok fine i might be the only one). > > > > Ah, so /you're/ the Netbeans guy. Good to meet you at last ;-) > > > > > But more importantly this is > > > something which is quite personal in terms of developer productivity > > > and I think there is value in the community avoiding having a > > > preferred IDE. > > > > +1 - definitely personal taste and not a project requirement. > > > > Regards, > > Tim > > > > > On Sun, Jul 17, 2016 at 1:05 PM, Suneel Marthi <[email protected]> > > wrote: > > >> I have been looking over the code the past week (mostly me getting > > >> familiarized with the project), I did not notice that the coding > > standards > > >> are more in line with what Eclipse enforces (which is barely > anything). > > >> > > >> I think all committers should be using IntelliJ for coding, u get an > > Apache > > >> committer's license from Jetbrains for the Ultimate edition of > IntelliJ > > - > > >> > > >> <goog_1576328420> > > >> https://www.jetbrains.com/shop/eform/apache?product=ALL > > >> > > >> The coding standards are pretty standard across most Apache Java > > projects - > > >> we could follow NiFi on this. > > >> > > >> Also what would be the minimal supported JDK for Pirk ? We shuld > > baseline > > >> at Java >= 7 IMO. > > >
