[FIXED] Automatically finding implicit type conversions (auto-boxing/auto-unboxing)

Issue

I've inherited a project where "identical" instance variables are used inconsistently. For example in some classes they are stored as the primitive float:

class Primitive {
  float myPrimitiveFloat;
  ...
}

..and in other classes, when the "same" variable is passed into the constructor, the value is stored as the boxed type Float:

class Boxed {
  Float myBoxedFloat;
  ...
  Boxed(Float myFloat, .. ) {
    this.myFloat = myFloat;
  }
}

..and then calling new Boxed(myPrimitiveFloat, ..) from a method in Primitive.

I'm using float/Float as examples here, but this inconsistency could be any of the other couples too: byte/Byte, short/Short, int/Integer, long/Long double/Double, boolean/Boolean and char/Char.

I find it would be consistent if the type would be either the primitive float or the boxed type Float for the "same" variable, and I am looking for a way of examining the source code, without having to visit each file individually.

As examples the things I'd like to be looking for is when a float being passed when a Float is required or vice versa. That could be (the list is not exhaustive, there could be others):

• A call to a constructor (new MyClass(..)) using a variable of a type that is opposite to the type in the constructor.
• When the passed in parameter to a setter is opposite to the parameter of the method, as in setMyVaribale(..)
• When a getter is returning the opposite to the instance variable type it's getting. Like float getMyValue() where the class stores myValue as a Float.

My local Java editor/toolkit is NetBeans and its internal type checker is Sonar lint. I'm discouraged from using software that is deemed "not standard" by my company. This includes the Eclipse IDE.

The Development envrionment is Java version 11.

Is there any way of configuring Sonar lint or NetBeans to detect this sort of thing, or possible detect it while building using Maven/Gradle?

Generate a log file that could be used as input to an audit review would be useful as well.

Solution

One possible solution is to add a report section to the POM file. When building with mvn site (it can take a while), an HTML page (target/site/index.html) or an XML file (target/spotbugsXml.xml) describing the issues will be generated.

Anything tagged with the pattern Bx: indicates the use of a dubious programming issue using boxing/unboxing from the spotbugs viewpoint.

The XML file could be used as input for an audit trail review.

The reporting section described below also invokes some other static code analysis tools which may also indicate other issues which might need to be resolved.

 <reporting>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-project-info-reports-plugin</artifactId>
            <version>${maven-project-info.version}</version>
            <reportSets>
                <reportSet>
                    <reports>
                        <report>index</report>
                        <report>ci-management</report> 
                        <report>dependencies</report>
                        <report>dependency-convergence</report>
                        <report>dependency-info</report>
                        <report>dependency-management</report>
                        <report>distribution-management</report>
                        <report>issue-management</report>
                        <report>licenses</report>
                        <report>mailing-lists</report>
                        <report>modules</report>
                        <report>plugin-management</report>
                        <report>plugins</report>
                        <report>scm</report>
                        <report>summary</report>
                        <report>team</report>
                    </reports>
                </reportSet>
            </reportSets>
        </plugin>

        <plugin>
            <groupId>com.github.spotbugs</groupId>
            <artifactId>spotbugs-maven-plugin</artifactId>
            <version>4.2.0</version>
            <configuration>
                <effort>Max</effort>
                <threshold>low</threshold>
                <xmlOutput>true</xmlOutput>
            </configuration>
        </plugin> 

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-pmd-plugin</artifactId>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <reportSets>
                <reportSet>
                    <id>html</id>
                    <configuration>
                        <doctitle>My API for ${project.name} ${project.version}</doctitle>
                        <windowtitle>My API for ${project.name} ${project.version}</windowtitle>
                    </configuration>
                    <reports>
                        <report>javadoc</report>
                    </reports>
                </reportSet>
                <reportSet>
                    <id>test-html</id>
                    <configuration>
                        <testDoctitle>My Test API for ${project.name} ${project.version}</testDoctitle>
                        <testWindowtitle>My Test API for ${project.name} ${project.version}</testWindowtitle>
                    </configuration>
                    <reports>
                        <report>test-javadoc</report>
                    </reports>
                </reportSet>
            </reportSets>
        </plugin>
    </plugins>
</reporting>

An entry of the spotbugs Maven page suggests that this is only guaranteed to work with Java 8. This code has been tested with Java version 8 and 11 and no problems were encountered.

More information about spotbugs can be found at Spotbugs maven plugin

Answered By - Dave
Answer Checked By - Candace Johnson (JavaFixing Volunteer)