A Java 1.5 Parser with AST generation and visitor support. The AST records the source code structure, javadoc and comments. It is also possible to change the AST nodes or create new ones to modify the source code.
https://code.google.com/p/javaparser/
Issue 57: https://code.google.com/p/javaparser/issues/detail?id=57&colspec=ID%20Type%20Status%20Stars%20Summary
Problem:

What steps will reproduce the problem?

1. Create a compilation unit of this signature: public void recordInterfaces(DisambiguateProperties<JSType>.Property p) {} 
2. Use a DumpVisitor to print the AST
What is the expected output? What do you see instead?
The expected output should be:
 public void recordInterfaces(DisambiguateProperties<JSType>.Property p) {} 
Instead, it is:
 public void recordInterfaces(DisambiguateProperties<JSType>.Property<JSType> p) {} 

The generics JSType of class DisambiguateProperties is wrongly associated to Property class.

Analyzed Result

Result from Ziyuan:


The first predicate above is not output to the users for the reason that it is not refined by selective sampling. Thus, the first classifier which we identify is the following (notice a disjunction here simply means two classifiers):

japa.parser.ASTParser:1755 (debugLine: 1767)
suspiciousness: 0.80
Logic: (type.typeArgs.isNull == true)
Accuracy: 1

Remarks

The bug is at line 1810 of class ASTParser: this line should be changed from ";" to "typeArgs = null;".

We have this block of code at ASTParser, line 1797:

for the input:
public void recordInterfaces(DisambiguateProperties<JSType>.Property p) {}
The first time of the loop, it parses and create a ClassOrInterfaceType with typeArgs = JSType for DisambiguateProperties<JSType.
At the second time, when it parses Property, although hasTypeArgument = false, because typeArgs is already dirty and is not reseted, the ClassOrInterfaceType created for Property also has typeArgs = JSType.
That's the reason of the bug.

Daikon

We feed the passed test cases from Ziyuan to Daikon. After 15 minutes, Daikon only creates a trace file larger than 1GB and does not produce any invariants. So we have to terminate it.

FailureDoc

The input of FailureDoc is a sequence. In this case, we manually create below sequence as its input. However, FailureDoc says that the sequence has not error and does not give any explanation.

START SEQUENCE

var0 = prim : java.lang.String:"Issue57" :

var1 = method : japa.parser.ast.test.Helper.readClass(java.lang.String) : var0

var2 = method : japa.parser.ast.test.Helper.parserString(java.lang.String) : var1

var3 = method : japa.parser.ast.Node.toString() : var2

var4 = method : org.junit.Assert.assertEquals(java.lang.Object,java.lang.Object) : var1 var3

END SEQUENCE