eclipse
automatic repair of Java 14 breakages
It is known that the API of Java 14 has changed much, and this breaks many projects.
This currently impact many projects because CI depends on docker image maven:latest which switched to java 14. (example: https://github.com/INRIA/spoon/issues/3486)
It would be great to provide a specific repair strategy to repair this error, and @javierron has found a way to diagnose the problem in the logs, see https://github.com/eclipse/repairnator/pull/1092#issuecomment-664600768
Hi @monperrus!
I have some doubts about this issue.
First of all, the original error shows up on a GitLab CI build, which I don't think Repairnator supports. Additionally, the issue with the docker image maven:latest using java 14 would only shows up on pipelines that run on docker containers, which is not always the case on Travis CI.
Noting this, I simulated the same issue on Travis CI using the Spoon project. I got this failed build.
I then did some experimenting with Repairnator and got stuck with an issue. When I run Repairnator pipeline, directly with java or using the latest docker image, I get the following result:
16:34:37.315 [main] INFO f.i.s.r.p.i.ProjectInspector - PIPELINE FINDING: NOTFAILING
So now I am stuck on replicating the failure, as the TestProject step is successful. As far as I understood, this happens due to the CI environment not being account for.
Do you have any advice about this?
Thanks a lot for the clear and detailed analysis notes.
When I run Repairnator pipeline, directly with java or using the latest docker image, I get the following result:
In docker, that's normal because the Docker image embeds the right version of the JVM (likely 1.8, by the way see #1129)
When using the pipeline in pure Java, it should fail if we make sure to use the JVM 14. Which JVM do you use in your experiment?
When using the pipeline in pure Java, it should fail if we make sure to use the JVM 14. Which JVM do you use in your experiment?
I used Oracle's JDK8.
The problem with 14 (or any >= 9) is that tools.jar was removed. I tried JVM 14 and 15 and they both present the same issue, Repairnator doesn't compile/run.
So, as far as I understood, the Java environment that Repairnator uses to reproduce builds is the same in which it is running.
Maybe it would make sense to change this, and have Repairnator reproduce builds in a sand-boxed environment that is generated according to the CI setup of the project being inspected? Because, as it sits, Repairnator wouldn't be able to properly reproduce builds of projects that are not compatible with the JVM in which Repairnator is running.
have Repairnator reproduce builds in a sand-boxed environment that is generated according to the CI setup of the project being inspected?
That's an excellent idea. Would you create an issue to keep track of it?
I tried JVM 14 and 15 and they both present the same issue, Repairnator doesn't compile/run.
Do you mean Repairnator itself doesn't compile? If yes, this should not happen. Repairnator should always compile. There is only one case where tools.jar is required, at runtime, when using Nopol as repair tool. Maybe we also need an issue "Make Repairnator compile on Java 14"
That's an excellent idea. Would you create an issue to keep track of it?
Yes, see #1132 .
Do you mean Repairnator itself doesn't compile? If yes, this should not happen. Repairnator should always compile. There is only one case where tools.jar is required, at runtime, when using Nopol as repair tool. Maybe we also need an issue "Make Repairnator compile on Java 14"
Yes, Repairnator pipeline itself does not compile. I've created #1133 .
I can tackle both of them, maybe starting off by the second one.
maybe starting off by the second one.
Good plan, works for me. We'll discuss later about #1132.