[
https://issues.apache.org/jira/browse/FINERACT-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141207#comment-17141207
]
Michael Vorburger commented on FINERACT-959:
--------------------------------------------
[~natashan] and [~Percy Ashu] I just had a closer look at
https://github.com/apache/fineract/blob/develop/fineract-provider/build.gradle#L372
and compared that with the output of {{javac -X}} (shown below), and now
understand that we have enabled all that we could. I have just closed the only
remaining open subtask FINERACT-1026 re. classfile. Do you have any objections
if we Resolve this issue now?
{noformat}
-Xlint Enable recommended warnings
-Xlint:<key>(,<key>)*
Warnings to enable or disable, separated by comma.
Precede a key by - to disable the specified warning.
Supported keys are:
all Enable all warnings
auxiliaryclass Warn about an auxiliary class that is hidden in
a source file, and is used from other files.
cast Warn about use of unnecessary casts.
classfile Warn about issues related to classfile contents.
deprecation Warn about use of deprecated items.
dep-ann Warn about items marked as deprecated in JavaDoc
but not using the @Deprecated annotation.
divzero Warn about division by constant integer 0.
empty Warn about empty statement after if.
exports Warn about issues regarding module exports.
fallthrough Warn about falling through from one case of a
switch statement to the next.
finally Warn about finally clauses that do not terminate
normally.
module Warn about module system related issues.
opens Warn about issues regarding module opens.
options Warn about issues relating to use of command
line options.
overloads Warn about issues regarding method overloads.
overrides Warn about issues regarding method overrides.
path Warn about invalid path elements on the command
line.
processing Warn about issues regarding annotation
processing.
rawtypes Warn about use of raw types.
removal Warn about use of API that has been marked for
removal.
requires-automatic Warn about use of automatic modules in the
requires clauses.
requires-transitive-automatic Warn about automatic modules in
requires transitive.
serial Warn about Serializable classes that do not
provide a serial version ID.
Also warn about access to non-public members from
a serializable element.
static Warn about accessing a static member using an
instance.
try Warn about issues relating to use of try blocks
(i.e. try-with-resources).
unchecked Warn about unchecked operations.
varargs Warn about potentially unsafe vararg methods
preview Warn about use of preview language features
none Disable all warnings{noformat}
[~ptuomola] FYI.
> 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)
