Vscode-java: When having VS Code open on a project that has a generated code srcDir, and running gradle commands from the command-line in that same folder, lock contention issues cause corrupted artifacts

[rubin55]

Expected Behavior

I'm using VS Code 1.17.2 + vscode-java 0.12.0, gradle 4.2.1 to build a Java 8 SpringBoot application om macOS 10.12.6. The build uses an xjc ant task to generate .java files from a few .xsd documents in the resources directory. I've verified that in my case, 11 ObjectFactory.java files are generated, and consequently, 11 ObjectFactory.class files are compiled correctly. I would expect all of those class files to end up in my resulting .war artifact.

Current Behavior

A random number of ObjectFactory.class files end up in the .war file. To verify this, see how to reproduce below.

Context

The issue occurs when vscode is open on a project which contains a generated code folder, specified as a srcDir entry in the build.gradle, and a terminal on the same project is used to run gradle commands. It looks like gradle from the command-line is competing with vscode-java/eclipse-jdt-ls/buildship for locks on files.

Note that it has been observed that specifying options.fork in the compileJava {..} section also works around the problem, although I suspect that only happens due to timing (i.e, think this is a race condition/lock contention of sorts).

Steps to Reproduce

1. Git clone reproducer (git clone [email protected]:rubin55/reproducer.git)
2. Open reproducer as folder in vscode
3. Let vscode initialize, open a few Java files to see that class lookup works
4. In particular, open a .java file from the generated source folder
5. Open a terminal and cd to the reproducer
6. Run this, a few times in a row:

gradle clean build && echo I found $(unzip -l build/libs/*.war | grep ObjectFactory.class | wc -l) ObjectFactory objects in archive while $(find build/classes/ -type f -name ObjectFactory.class | wc -l) were compiled and $(find build/generated/ -type f -name ObjectFactory.java | wc -l) java files where generated

Example output:

I found 1 ObjectFactory objects in archive while 11 were compiled and 11 java files where generated

1. If the issue manifests, you will see that the resultant .war file will have missing ObjectFactory.class files (see message above).
2. Observe vscode-java .log file and see backtraces that coincide with this issue. See attached vscode-java.log.

Your Environment

VS Code 1.17.2
VS Code Java 0.12.0
Gradle 4.2.1
Java 8 r144
macOS 10.12.6

[fbricon]

Have you checked if this is reproducible with Eclipse+Buildship?

[rubin55]

I downloaded Eclipse Oxygen for Java Developers and opened the project. I opened a few generated files, checked if everything resolved normally and started my commandline gradle build commands as detailed under steps-to-reproduce. I ran 20 builds, 0/20 had missing ObjectFactory.class objects in the .war.

After re-doing the same with VS Code, 2/10 builds had missing ObjectFactory.class objects in the .war. Immediately after that, re-did a couple in Eclipse: 0/10.

Note that I cannot predict exactly when it happens. only that it happens for sure at least once in 20 runs.

[rubin55]

I just ran this on Windows 10 x64, otherwise identical VSCode/Java/Gradle versions. First build had missing objects, so it's not an isolated macOS specific issue.

[IzakMarais]

I actually get very similar problems with maven on Windows 8. I have multi-module maven builds and running mvn clean install while VSCode is open sometimes doesn't generate all the .class files it should (no compiler error). When I close VScode and run mvn clean install it works. Somehow the java language server is causing contention with the java compiler.

I also have generated sources in my multi-module project, for what its worth.

[jbelford]

This is an error I am still running into. I also have a multi-module maven project and have to close vs code everytime I mvn clean install because there seems to be file locks on my target directories and the builds fail when they try to delete those.

[IzakMarais]

Can we add a maven tag to this issue (or remove the gradle tag)? It doesn't seem like the build tool itself is relevant since similar behaviour is observed for both maven and gradle builds.

[jbelford]

I'm no longer getting this issue when I added my target folders to be excluded from the file watcher.

"files.watcherExclude": {
        "**/target/**": true
},

Not sure if this impacts anything else. I'm guessing its possible that excluding the build folder from gradle might also stop this issue for gradle projects.

[kusnier]

I'm no longer getting this issue when I added my target folders to be excluded from the file watcher.

"files.watcherExclude": {
        "**/target/**": true
},

Not sure if this impacts anything else. I'm guessing its possible that excluding the build folder from gradle might also stop this issue for gradle projects.

This solved also my problem with a sub-module project in maven.
Host system: linux

mvn -veraion
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512M; support was removed in 8.0
Picked up _JAVA_OPTIONS: -Djava.awt.headless=true
Apache Maven 3.6.0
Maven home: /usr/share/maven
Java version: 1.8.0_212, vendor: Amazon.com Inc., runtime: /usr/lib/jvm/java-1.8.0-amazon-corretto/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-58-generic", arch: "amd64", family: "uni

[arcarchit]

I'm no longer getting this issue when I added my target folders to be excluded from the file watcher.

"files.watcherExclude": {
        "**/target/**": true
},

Not sure if this impacts anything else. I'm guessing its possible that excluding the build folder from gradle might also stop this issue for gradle projects.

In which file shall we add this ?

[ledsoft]

I'm no longer getting this issue when I added my target folders to be excluded from the file watcher.

"files.watcherExclude": {
        "**/target/**": true
},

Not sure if this impacts anything else. I'm guessing its possible that excluding the build folder from gradle might also stop this issue for gradle projects.

In which file shall we add this ?

That would be settings.json.