[ 
https://issues.apache.org/jira/browse/FINERACT-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127015#comment-17127015
 ] 

Natasha Natarajan commented on FINERACT-959:
--------------------------------------------

[~Percy Ashu], I didn't realize that you had already done work on this. Please 
let me know if you want to coordinate on the rest of the outstanding lint 
checks? Perhaps, we can create subtasks as needed?

If not, let me know if you prefer to work on this and I will take myself off.

> Tighten javac compilerArgs, turn more warnings into errors (and fix related 
> problems)
> -------------------------------------------------------------------------------------
>
>                 Key: FINERACT-959
>                 URL: https://issues.apache.org/jira/browse/FINERACT-959
>             Project: Apache Fineract
>          Issue Type: Improvement
>            Reporter: Michael Vorburger
>            Assignee: Natasha Natarajan
>            Priority: Major
>              Labels: quality, technical
>             Fix For: 1.4.0
>
>
> In the context of FINERACT-828, I just noticed that 
> org.apache.fineract.notification.domain.Notification.setActor(Long) has an 
> obvious bug (which I'm fixing in a PR related to FINERACT-828).
> Eclipse pointed out that particular problem - as 1 out of 888 Warnings! :P
> One thing that IMHO would be interesting and valuable in overall context of 
> our ongoing code quality efforts under the umbrella of FINERACT-712 would be 
> to not only (also!) increasingly engage 3rd-party Java code quality tools (as 
> we already are, very much ongoing... [~Manthan] GSOC), but also leverage what 
> javac can do for us!
> Something neat [~ptuomola] did in FINERACT-846 as part of our switch to Java 
> 11 was to enable {{'-Xlint:unchecked'}} and {{deprecation}} warnings (search 
> for this in our {{build.gradle}}). Can we turn more javac warnings into 
> errors - and fix respective problems?
> [~natashan] (Outreachy, like GSOC) perhaps this is something you'd like to 
> dig into?
> PS: There is also the theoretical possibility to run Eclipse's Java Compiler 
> (JDT) headlessly on the build - JUST because it sometimes has more feedback 
> about code than javac. http://www.lastnpe.org does this for null analysis. 
> (This is much more involved than just standard {{javac}}, so we should start 
> there.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to