Update CocospoonLocalizer2Test to expose the cocospoon problem in JDK 1.7

[DehengYang]

No description provided.

[DehengYang]

I have been studying on this pull request for serveral hours. And I have made some progress. Thank you so much for making Nopol branch March2017 available !

In this process, I have met a problem: (see https://travis-ci.org/SpoonLabs/nopol/jobs/494171137 )

testOchiaiCoCoSpoonLocalizer(fr.inria.lille.localization.CocospoonLocalizer2Test) Time elapsed: 24.736 sec <<< ERROR!

java.lang.NoSuchMethodError: spoon.reflect.code.CtBlock.addStatement(ILspoon/reflect/code/CtStatement;)Lspoon/reflect/code/CtStatementList;

at fil.iagl.opl.cocospoon.insert.impl.SynchronizedInsert.apply(SynchronizedInsert.java:18)

at fil.iagl.opl.cocospoon.processors.WatcherProcessor.instrumentLine(WatcherProcessor.java:80)

at fil.iagl.opl.cocospoon.processors.WatcherProcessor.findMatcherAndApply(WatcherProcessor.java:63)

at fil.iagl.opl.cocospoon.processors.WatcherProcessor.process(WatcherProcessor.java:55)

at fil.iagl.opl.cocospoon.processors.WatcherProcessor.process(WatcherProcessor.java:16)

at spoon.support.visitor.ProcessingVisitor.scan(ProcessingVisitor.java:92)

at spoon.support.RuntimeProcessingManager.process(RuntimeProcessingManager.java:145)

at spoon.support.RuntimeProcessingManager.process(RuntimeProcessingManager.java:133)

at fr.inria.lille.commons.spoon.SpoonedFile.processModelledClasses(SpoonedFile.java:152)

at fr.inria.lille.commons.spoon.SpoonedFile.process(SpoonedFile.java:143)

at fr.inria.lille.commons.spoon.SpoonedFile.processedAndDumpedToClassLoader(SpoonedFile.java:134)

at fr.inria.lille.commons.spoon.SpoonedFile.processedAndDumpedToClassLoader(SpoonedFile.java:130)

at fr.inria.lille.localization.CocoSpoonBasedSpectrumBasedFaultLocalizer.runTests(CocoSpoonBasedSpectrumBasedFaultLocalizer.java:33)

at fr.inria.lille.localization.DumbFaultLocalizerImpl.(DumbFaultLocalizerImpl.java:30)

at fr.inria.lille.localization.CocoSpoonBasedSpectrumBasedFaultLocalizer.(CocoSpoonBasedSpectrumBasedFaultLocalizer.java:26)

at fr.inria.lille.localization.CocospoonLocalizer2Test.testOchiaiCoCoSpoonLocalizer(CocospoonLocalizer2Test.java:58)

This is caused by the version cocospoon. I cannot find the version of cocospoon proposed in March 2017, thus I used the current Nopol version (compat-java7). As a result, the NoSuchMethodError occured in the travis build process in jdk 1.7.

Could you also offer Cocospoon branch like March2017 (like Nopol branch March2017)? Reproducing the RuntimeException relies on both Nopol branch March2017 and Cocospoon branch March2017.

Thank you again for your help!

[monperrus]

Done, see 3242c21

[DehengYang]

Thank you so much for your help!

I think the bug reproducing process is already at the corner, but I have met two problems before reaching expected output, with one solved and one unsolved:

The first problem is that oraclejdk7 is not available in Travis any more. By searching inside the Travis doc, I find a solution that changes oraclejdk7 to openjdk7 ( see https://docs.travis-ci.com/user/reference/trusty ), after which the jdk 1.7 is available.

The second problem, which still remains unsolved, is that Travis Maven fail to download jar org.eclipse.jdt:org.eclipse.jdt.core:jar:3.12.0.v20160516-2131, the running info is as follow ( see https://travis-ci.org/SpoonLabs/nopol/jobs/494677466 ):

[ERROR] Failed to execute goal on project CocoSpoon: Could not resolve dependencies for project fil.iagl.cocospoon:CocoSpoon:jar:1.0.0-SNAPSHOT: Could not find artifact org.eclipse.jdt:org.eclipse.jdt.core:jar:3.12.0.v20160516-2131 in central (http://repo.maven.apache.org/maven2) -> [Help 1]

For this problem, I have searched a lot on the internet but fail to find the solution. Maybe I am still not familiar with how the maven manage the dependencies. After several hours' attempts, I have some findings:

1. org.eclipse.jdt:org.eclipse.jdt.core:jar:3.12.0.v20160516-2131 does not exist in https://repo1.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.core/ any more. ( see https://mvnrepository.com/artifact/org.eclipse.tycho/org.eclipse.jdt.core/3.12.0.v20160516-2131 and https://repo1.maven.org/maven2/org/eclipse/jdt/org.eclipse.jdt.core/ )
2. I cannot find any statement about org.eclipse.jdt:org.eclipse.jdt.core:jar:3.12.0.v20160516-2131 in the pom.xml of cocospoon, so I do not know why maven would download this dependency.

This is my current report. Much appreciated if any help can be offered to solve the second problem.

Thank you again for your help!

[monperrus]

This very version version was not released under "org.eclipse.jdt" but under "org.eclipse.tycho".   The solution is to replace groupid="org.eclipse.jdt" by groupId="org.eclipse.tycho", see https://mvnrepository.com/artifact/org.eclipse.tycho/org.eclipse.jdt.core/3.12.0.v20160516-2131

[DehengYang]

After hours of study, I have found a solution to solve the dependency (named org.eclipse.jdt:org.eclipse.jdt.core:jar:3.12.0.v20160516-2131) of CoCoSpoon by modifying the .travis.yml. I originally wanted to

replace groupid="org.eclipse.jdt" by groupId="org.eclipse.tycho"

according to your guidance. But I cannot find any lines like groupid="org.eclipse.jdt" in the pom.xml in CoCospoon project. Therefore, I modified the .travis.yml to deal with this problem.

The running ouptut has reached the expected result (i.e., exposing the java.util.concurrent.TimeoutException) now, see https://travis-ci.org/SpoonLabs/nopol/jobs/495245658 :

This is the repoducing result. Thank you for your help!

[DehengYang]

I thought I have found the solution.

This is actually not a bug. This RuntimeoutException occurs because of the configuration in March2017 Nopol (see the file nopol/nopol/src/main/resources/config.ini https://github.com/DehengYang/nopol/blob/march2017/nopol/src/main/resources/config.ini )

[general]
complianceLevel=7
timeoutTestExecution=5

The timeoutTestExecution is so short that the java.util.concurrent.TimeoutException will Inevitably occurs when the Nopol run real-world test from defects4j project. When I increase the timeoutTestExecution from 5 to 200, the java.util.concurrent.TimeoutException is wiped out.

I am sorry that I have misunderstood the root cause of java.util.concurrent.TimeoutException. I originally thought it was caused by the external jar java.util.concurrent.futuretask or the cocospoon.jar. Thus I propose the issue and corresponding pull request, as I think dealing with these jars is out of my ability.

I have never giving up finding the reasons behind. Now I have solved this. But actually, this java.util.concurrent.TimeoutException has been solved since Mr. Durieux's commit in Nov 2017 (see 2ceef83#diff-08aec1ce026bdf1106cc97d42e0c5daa ).

Though this is not seriously a bug, the process of reproducing the exception and finding the root cause means a lot. Additioally, the Nopol Nov 2017 version, which increases the timeoutTestExecution, may have the ability to repair more bugs from defects4j than the Nopol March 2017 version.( see https://github.com/Spirals-Team/defects4j-repair/tree/master/results/2017-march)

This is my report. Thank you for your great help!

[monperrus]

Great news, thanks for the follow up!