Looking forward to it! Thanks Erick! On Wed, 24 Jun, 2020, 7:26 am Erick Erickson, <erickerick...@gmail.com> wrote:
> re: checkstyle. Feel free to have at that debate ;) > > > On Jun 23, 2020, at 6:51 PM, Michael Sokolov <msoko...@gmail.com> wrote: > > > > +1 thanks huge step forward for code hygiene > > > > Maybe someday we will agree on a minimal check style enforcement too š® > ... > > Sorry, too soon? > > > > On Tue, Jun 23, 2020, 6:21 PM Anshum Gupta <ans...@anshumgupta.net> > wrote: > > Thanks, Erick! This is awesome :) > > > > On Tue, Jun 23, 2020 at 2:18 PM Erick Erickson <erickerick...@gmail.com> > wrote: > > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if > there are any warnings in the code. See LUCENE-9411. Iāve finally finished > suppressing over 8,000 warnings in Solr, so could check this in. Many > thanks to Dawid for helping me with the Gradle parts. The goal now is to > not add any _more_ SuppressWarnings if at all possible. I hope we can start > taking the suppressions out when weāre working on code, so when working on > code please consider removing some of them. > > > > I was hoping that we could also fail ant builds, but there are some > tricky dependencies in third party code that werenāt easy to resolve in the > ant world due to licensing issues, if youāre interested in details, see the > JIRA or ping me on Slack. One consequence of this is that 8x will NOT fail > on warnings, neither will Ant builds on 9x. If someone wants to try working > that out, please feel free but Iām just really tired of banging my head > against that wall. > > > > So please, Please, PLEASE start compiling 9x with Gradle or cover your > ears to keep from hearing me complain. And Iāve been taking lessons from my > 3 1/2 year old grandson on doing that LOUDLY. > > > > About SuppressWarnings. There were so many of them that there was no > hope of actually fixing the underlying causes in one go. Iāve enhanced the > BadApples report to start reporting on the number of SuppressWarnings in > each file week to week when they increase or decrease. Iāll be nudging > people if the number of SuppressWarnings starts going up, starting Monday. > I canāt help but think understanding generics will be improved by working > through new warnings. > > > > A couple of side notes for IntelliJ users (IDK about other IDEs, but Iād > be surprised if there werenāt similar capabilities): > > > > - When you just open the project, Gradle is automatically configured. > Thereās no need to execute the āgradlew ideaā task. > > > > - You can execute tasks in IntelliJ _really easily_ by clicking on them > in the gradle window, itās on the extreme right. It seems much more robust > than trying the same thing in Ant. > > > > -- The āassembleā task will bring up a convenient window showing errors > (including warnings) that you can click on and get right to the offending > code. āclassesā and ātestClassesā are also very useful tasks to execute in > this context. > > > > - The āinspectionsā in IntelliJ point out a lot of things, but not > anything with SuppressWarnings. It may be worth coming to consensus on > which inspections are worth enabling. And perhaps distributing a > configuration. For instance, do we really care for inspections reporting > āblah could be finalā? Theyāre highlighted in yellow in my setup, and Iāve > done nothing special. Spend some time looking at those when youāre working > on code⦠the number of āmethod may return nullā inspections is scary. Have > weāve ever had the released code generate an NPE or anything like that > <snark/>. > > > > - Please do NOT suppress the _inspections_ in IntelliJ. One of the > choices IntelliJ offers is to suppress an inspection, and it adds a > āsuppressInspectionā comment to the source code specific to IntelliJ. This > is different than Javasās SuppressWarnings, and we shouldnāt include > comments in the code specific to a particular IDE. > > > > - The motivation here is that we need all the help from the compiler we > can get when it comes to as large and complex a code base as Lucene/Solr. > Yes, it feels constraining. Yes, it means we wonāt feel as productive > because we have to take time to address things weāve been ignoring. The > leap of faith is that if we spend a bit of time up front, we can avoid > having to spend a lot _more_ time fixing errors later in the release cycle. > The time it takes to fix a problem goes up exponentially the farther down > the cycle itās caught. Fixing something when developing may take T minutes. > Some time later when test start failing, it takes T*X. And when you > consider community-wide implications of releasing code, getting feedback > from the field, filing a JIRA, trying to reproduce the problem, checking > the code, and pushing a fix, the cost of fixing something after itās > released goes up enormously. Iām not saying that addressing all the > complaints something like IntelliJās inspections show will magically make > it unnecessary to make point releases, but avoiding just a few is a win. > <rant/> > > > > Erick > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > -- > > Anshum Gupta > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >