讲解Eclipse JDT、辅导Java程序、讲解AST留学生、Java编程辅导讲解

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.

2Bug 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

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).

3Testing 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.

4Discussing your detection results.

You need to run your tool on two systems: Hadoop 3.0.06  and CloudStack 4.97.

5From https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf 6https://github.com/apache/hadoop/tree/branch-3.0.0 7https://github.com/apache/cloudstack/tree/4.9

For bug pattern 1–4, you need to compare your detection results with that of FindBugs (since FindBugs is also able to detect these bugs). Whenever there is any difference in the detection result, you need to include a discussion in your final report regarding why the difference exist.

5Final report.

The final report must be in ACM conference format (i.e., double column). You can find an example here. You can also find the template file on the course website. Note that you have to follow the template; otherwise, you will lose marks in the assignment.

You need to use this option in your latex file: \documentclass[sigconf]{acmart}

The final report should contain five or more pages. It needs to include (at least): abstract, introduction, detection approach, design of the test cases, detection result and discussion, and conclusion. You must include the link to your GitHub repository in the report.

The final format of the report must be in .pdf format.

6Hosting code and report on GitHub.

Everything needs to be stored on GitHub, including all of your code, test case, and report. The report should preferable be written in Latex. However, if you struggle with Latex, you may also use other tools (e.g., Google Doc), as long as it can show the edit/version history.

Please make your repository private.  You may also use BitBucket or  GitLab.