SpoonLabs / astor

Automatic program repair for Java with generate-and-validate techniques :v::v:: jGenProg (2014) - jMutRepair (2016) - jKali (2016) - DeepRepair (2017) - Cardumen (2018) - 3sfix (2018)
https://hal.archives-ouvertes.fr/hal-01321615/document
GNU General Public License v2.0
208 stars 106 forks source link

JDK14 -Astor #243

Open ssk1216 opened 4 years ago

ssk1216 commented 4 years ago

Is it mandatory that i should have JDk8 for astor.??? I have JDK 14, and the astor compilation failed with the below error

Failed to execute goal on project astor: Could not resolve dependencies for project org.inria.sacha.automaticRepair:astor:jar:1.0.0-SNAPSHOT: Could not find artifact com.sun:tools:jar:1.4.2 at specified path /usr/lib/jvm/jdk-14.0.2/../lib/tools.jar ->

martinezmatias commented 4 years ago

Hi @ssk1216 I would recommend to install and execute Astor on a JDK 8 or 9. I have not executed it on a JDK 14, but I faced some problems on JDK 11. Regards Matias

lapplislazuli commented 3 years ago

I can confirm I have the exact same issue on Java 15.

The only way to work around this is to "downgrade" your JDK to 8, otherwise you are unlikely to use the suggested mvn install. Even if you go for jenvs you will have a bit of a trouble as the install puts stuff somewhere not super linked to your java home.

You might also compile it using jdk8 and then you can run the jar specifying the vm, but meh 😞 .

I think the docker approach might be best.

However, there is no repository where the docker comes from and last push was 2 years ago. @martinezmatias Do you think contributing a (new) dockerfile to this repository would benefit the project?

martinezmatias commented 3 years ago

Hi @Twonki

Do you think contributing a (new) dockerfile to this repository would benefit the project?

Absolutely! Contributions are very welcome and more specially those that would allow to compile and execute Astor on JVM+9

Regards Matias

lapplislazuli commented 3 years ago

Looking into it @martinezmatias

The "bad" dependency is

<dependency>
    <groupId>fr.inria.gforge.spirals</groupId>
    <artifactId>nopol</artifactId>
    <version>0.2-SNAPSHOT</version>
</dependency>

once you move it out, the com.sun.tools is not needed anymore. Obviously if you just comment it out it doesn't compile but to me it looks like Nopol is the single point blocking newer java.

martinezmatias commented 3 years ago

Hi @martinezmatias

Yes, the reason of depending on Nopol is that we use some functionality from it on some repair approaches implementations