SOEN 7481 Software Verification and Testing Fall 2018 1 Assignment Description. In this assignment, you will need to implement a static analysis tool to detect bugs in source code. Static analysis tools are commonly used as part of the continuous integration process to ensure the quality of the code (more details in the slides and the papers in week 3). The tool will be implemented in Java. There are two tools that you may use to help you with analyzing the code: Eclipse JDT, an Abstract Syntax Tree (AST) parser that is part of the Eclipse IDE. JavaParser, an open source AST parser for Java. 2 Bug Patterns. You will need to implement a total of 10 bug patterns. The descriptions of the bug patterns are listed below: 1. Class defines equals() but not hashCode(). This class overrides equals(Object), but does not override hashCode(). Therefore, the class may violate the invariant that equal objects must have equal hashcodes. From FindBugs1 2. Comparison of String objects using == or !=. This code compares java.lang.String objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the String.intern() method, the same string value may be represented by two different String objects. Consider using the equals(Object) method instead. From FindBugs2 3. Method may fail to close stream on exception. The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed. From FindBugs3 4. Condition has no effect. This condition always produces the same result as the value of the involved variable was narrowed before. Namely, the condition or the boolean variable in if/while always returns either true or false. Probably something else was meant or condition can be removed. From FindBugs4 For example: if (true) {...} or boolean var = false; if (var) {...} 1http://findbugs.sourceforge.net/bugDescriptions.html#HE EQUALS NO HASHCODE 2http://findbugs.sourceforge.net/bugDescriptions.html#ES COMPARING STRINGS WITH EQ 3http://findbugs.sourceforge.net/bugDescriptions.html#OS OPEN STREAM EXCEPTION PATH 4http://findbugs.sourceforge.net/bugDescriptions.html#UC USELESS CONDITION SOEN 7481 Fall 2018 Assignment #2 5. Inadequate logging information in catch blocks. Developers usually rely on logs for error diagnostics when exceptions occur. However, sometimes, duplicate logging statements in different catch blocks of the same try block may cause debugging difficulties since the logs fail to tell which exception occurred. For example: ... } catch (AlreadyClosedException closedException) { s_logger.warn("Connection to AMQP service is lost."); } catch (ConnectException connectException) { s_logger.warn("Connection to AMQP service is lost."); } ... 6. Unneeded computation in loops. There may be unneeded computation in loops, where you call a method inside a loop, but the return value is never used. For example: ... for (int i = 0; i < 1000; i++){ Result r = computeResult(i); // unneeded computation doSomething(i); } ... 7. Unused methods. Detect both private and public methods that are not referenced/called anywhere in the code. 8. Empty exception. There is no debug message when an exception occurs, which may cause debugging difficulties.5 9. Unfinished exception handling code. There is a comment such as TODO or FIXME in the catch block of exceptions.5 10. Over-catching an exception with system-termination. Developers are over-catching an exception (i.e., catching very high-level exceptions, such as Exception or RunTimeException), and are calling abort or System.exit() in the catch block.5 Note that, you can use either FindBugs or SpotBugs, since these two are almost identical (SpotBugs is successor of FindBugs). 3 Testing your code. You will need to design test cases for your code. For each bug pattern, you need to design some test cases, and more importantly, you need to describe your design decision in the final report. You may use any testing framework (e.g., JUnit or TestNG) for your test case. There is no right or wrong answer in terms of test case design, but you must provide a valid reason for your design