Stop creating files in bin directory

[daliborfilus]

Random files begin to appear in my bin directory after I generated a lot of code by using my custom code generator. I spent a lot of time debugging where these files are being created, who and why makes them, and I don't want my project polluted with completely useless copies of the project files.

Environment

• Operating System: macOS 10.13
• JDK version: multiple
• Visual Studio Code version: Version 1.27.1 (1.27.1)
• Java extension version: 0.30.0

Steps To Reproduce

1. Open any kind of project, even non-java ones (mixed), click on any .java file
2. Watch .class files being generated in your bin directory, kotlin files being copied there as-is (which doesn't make any sense), other resources being copied there without any reason.

Current Result

Many files are copied to ./bin/ without any reason to do so.

Expected Result

No files are created, compiled, copied without developer's consent!

Additional Informations

The extension uses jdt_ws which creates these files. I don't want these files to be there, because:

1. I use docker.
2. I don't use vscode for java, I use it for other parts of the project.
3. I compile the java and kotlin files using gradle, to build folder, with multiple other build configuration options not reflected by vscode-java or jdt_ws.
4. The generated files are useless.
5. This extra compilation step burdens battery life and SSD wear.
6. It just doesn't make any sense.

I didn't even know that I have vscode-java installed and it took a LOT of digging to find out WHY and WHO creates these files!

Please consider removing them altogether, OR make this extra compilation step optional (opt-in) with explicit configuration where these files should be created.

If I would change the target directory to "build" or "target", then vs code would be randomly overwriting files compiled by docker/IDEA/gradle.

They might even be compiled with different version of Java (and JDK)!

[daliborfilus]

Don't get me wrong. I'm glad that this extension exists, it surely looks useful. But it was activated by default and this default "bin behavior" is totally unexpected and uwanted.

[akaroml]

@Eskibear please take a look as a part of the effort of handling temp files.

[nik9000]

I've been using this extension for about 9 months full time. A week or two ago these bin directories started popping up. We usually move all of Eclipse's gradle stuff over to a directory that we've gitignored. I'm not sure what has broken, but these bin directories are overwriting directories where we put things and breaking normal gradle runs. At this point the plugin I just have to uninstall the plugin.

[nik9000]

A week or two ago

I suspect me seeing this issue late might have something to do with not upgrading very quickly. I'm not sure though.

[tonny008]

right click pom.xml and update project configuration

this will generate the .project .classpath .settings files. it seems that the latest version will only generate .project by default. the class file will output to bin folder if there's no .classpath file

[ewired]

I solved this issue on Ubuntu by editing the .classpath XML file, replacing all bin/ with build/temp/ (just to use an example that was already gitignored for my convenience). Before doing that, having this extension enabled would make complete copies of Kotlin source files from the src/ folder to the bin/ folder upon saving. Oddly enough, after changing the .classpath file, it copies the folder structure and no Kotlin source files into build/temp/.

I'm a complete beginner to the Java ecosystem, so I don't know what effects this has long-term, but it works for me. Maybe it's worth exploring automatically editing that file to ensure that it no longer tampers with bin/.

The behavior on my setup contradicts tonny008's experience; I think this is due to using Kotlin and the Kotlin Language Server extension which has its own set of issues regarding dependency resolution. Upon starting VS Code, the plugin would re-create the .classpath, .project files and .settings folder, and also pollute the bin/ folder, and I am running the latest extension version. Even while the .classpath file was present and unmodified, it would still pollute the bin folder. As described previously, I edited the .classpath file in an attempt to make it pollute a different folder, and it worked.

[ckuai]

one more facing this problem. I found whenever I did "mvn eclipse:clean" "mvn eclipse:eclipse" to regenerate the .project and .classpath, then vscode will create a bin folder with all my project's sub folders and files moved under a new created bin folder and build output. Deleting the .factorypath file also has this effect. My .classpath file has no bin/ path at all. output attributes in .classpath are output="target/test-classes" or output="target/classes"

[Unichron]

Same issue here. From observation I think the main problem may be that when you don't have a .classpath, the plugin doesn't import the pom.xml/build.gradle first, but starts building the class files to the default output directory, which happens to be bin.

[Polish-Civil]

Making it configurable would be great thing todo

[testforstephen]

Reproduced the issue.

1. Use VS Code to open a maven project.
2. Wait the Java Language Server is ready. (:thumbsup: appears at the right bottom status bar)
3. Manually delete .classpath file, then a new bin folder is automatically created at the root folder, and all non java files are copied there.

Looks like if the .classpath doesn't exists, the Java projects loaded by jdt.ls will take bin as the default output folder. And the build process will take any files it doesn't know how to compile as resources, and copy them to the output folder.

[maxiwu]

Same issue. I don't understand. Maven project do not use anything from \bin.
How do I avoid this from happening? it messes up my git.

[dsculptor]

Any update on this issue? Seems like my scons build rules are finding multiple copies of themselves and conflicting!

[dsculptor]

I think this is a serious issue, and unfortunately the only solution for me right now is to use idea. sorry VSCODE-JAVA

[keefbaker]

Agreed. Until this stops, this extension is basically unusable.

[janbodnar]

This is gross. Removed the extension immediately. Not only it makes Java for Code unusable, it also ruins the reputation of the Code.

[acohen716]

Any update on this almost 1 year old issue? I've resorted to @ewired suggestion above

[talios]

I get this often and it's annoying as (#*$&#(# - esp. since it also copies .git folders into bin which REALLY mess up some tooling.

[talios]

@acohen716 the problem with @ewired's "solution" is you'd need to commit those .classpath files for those changes to persist. That's a worse sin in my book.

[Eskibear]

take bin as the default output folder. And the build process will take any files it doesn't know how to compile as resources, and copy them to the output folder.

Based on hypothesis mentioned in #634 (comment) above, I'm wondering if it would be a good solution that:

• If language server doesn't know how to compile as resources, stop doing further unexpected actions, simply notify the client (VSCode) about it.
• Then the client can prompt with the error, providing users a shortcut/guidance to fix the issues (e.g. to re-generate a .classpath file)

[Eskibear]

Here's another scenario blocked by the issue. I was working on a nodejs project in my workspace, then I dragged a HelloWorld.java in, pressed F5, and it just stuck on "compile workspace" for a long time (making no sense for the single .java file). Soon I realized it was copying the huge node_modules folder into the jdt_ws/<workspace>/bin folder.

Just FYI that this issue might be more severe than I thought before, especially for polyglot programmers.

[nemausus]

Extension is very promising but this issue is a big blocker for me as well.

[csurfer]

I was quite hopeful of VSCode's remote ability. Since most of my work is on Java + Python it would have been the ideal solution. This aspect of unwanted files in the bin directory is an issue for me as well.

[testforstephen]

Here's another scenario blocked by the issue. I was working on a nodejs project in my workspace, then I dragged a HelloWorld.java in, pressed F5, and it just stuck on "compile workspace" for a long time (making no sense for the single .java file). Soon I realized it was copying the huge node_modules folder into the jdt_ws/<workspace>/bin folder.

Just FYI that this issue might be more severe than I thought before, especially for polyglot programmers.

Currently JavaBuilder provides an option CORE_JAVA_BUILD_RESOURCE_COPY_FILTER to exclude the specified resources. It supports a file name pattern (* and ? wild-cards allowed) or the name of a folder which ends with '/'. For polyglot projects, you need list all possibles to exclude, it will be a burden.

Another idea is to add a new option (e.g. CORE_JAVA_BUILD_NO_RESOURCE_COPY) in the jdt core, if it's enabled, stop the copy behavior.

[dsculptor]

Any updates @snjeza ? Thanks.

[shua]

@Donraj check out eclipse-jdtls/eclipse.jdt.ls#1108 for updates on fix

[sparrowt]

#2344 is still open and (possibly) unblocked now, so here's hoping...

[MagnusMG]

My problem is that every so often I open a kotlin source file from the bin folder, without noticing that it is from the bin folder. And I make changes to that file. And three hours later I try to build the project, and all my changes are overwritten with the unchanged source file in the source folder.

I have disabled the extension now. It is a shame, because it is good apart from this.

[RolKau]

@sparrowt
This will probably never be fixed, because the developers seems to believe that it is an issue with the Gradle backend, despite that it happens with Maven projects, too. There seems to be a timing issue and/or something written to the workspace storage that triggers it.

[darchangels13]

@sparrowt This will probably never be fixed, because the developers seems to believe that it is an issue with the Gradle backend, despite that it happens with Maven projects, too. There seems to be a timing issue and/or something written to the workspace storage that triggers it.

It's the java language server that does it. When VS Code parses a java project it generates these files. You can improve the number of times this happens to you by turning off the Hybrid launch mode (otherwise you'll get it every time you start a workspace with open java projects) effectively degrading the performance of the editor. But you won't get away from this unless you switch to the lightweight server entirely, which really reduces the usefulness since that's mostly good for syntax and nothing more.

They recycled the an Eclipse project for this. Eclipse has a setting you can use to specify the output of its temporary class files, and when specified to overlap with your build/target directory it's not nearly as painful an experience. Unfortunately the VS Code extension doesn't seem to support configuration of this value and some combination of in-feasibility or intransigence has caused them pretend this is a non-issue that can't be reproduced or solved.

[RolKau]

Eclipse has a setting you can use to specify the output of its temporary class files, and when specified to overlap with your build/target directory it's not nearly as painful an experience

But it is not just regular output files, it is like the extension suddenly forgets that it is a Java language server and starts copying all files.

[darchangels13]

Eclipse has a setting you can use to specify the output of its temporary class files, and when specified to overlap with your build/target directory it's not nearly as painful an experience

But it is not just regular output files, it is like the extension suddenly forgets that it is a Java language server and starts copying all files.

@RolKau I haven't seen that one, not yet, in any event. I'm doing Gradle (+Spring) and it will very reliably build into that directory, a full set of class files, processed resources, etc. no package artifacts for me. It very much looks like the eclipse output from when I still used that beached whale of an editor.

And this used to be something you'd have to correct in every Eclipse project, but it was fine because, though it was obnoxious to do it, there was a setting and these settings would get checked in under the ".project" or one of the infinite number project bloatfiles eclipse generates. And then it would disappear until the next time you were setting up a project.

And hey if i can make a .project file for this to go away, I will. I'll actively resent it, but I'll do it. But this really should be something the VS Code Extension can configure. Nobody manages .class files in bin/ because the moment you're managing dependencies you've switched to one of several popular choices, not one of which uses bin/ for output.

[RolKau]

I'm doing Gradle (+Spring) and it will very reliably build into that directory, a full set of class files

For Maven it is far worse, because for each POM project, it will copy everything that is not a .java or .class file into the bin/ subdirectory.

these settings would get checked in under the ".project" or one of the infinite number project bloatfiles

I already have a .project file in each of the directories, but that said, your comment made me think that perhaps the problem is that there isn't any .classpath (because the POM projects don't have src or target), so I tried creating a minimal .classpath containing (non-directory fragments from a project at the time these files were generated in the source folder):

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-17">
        <attributes><attribute name="maven.pomderived" value="true"/></attributes>
    </classpathentry>
    <classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
        <attributes><attribute name="maven.pomderived" value="true"/></attributes>
    </classpathentry>
</classpath>

and although this seemed to cure the branch that was having the problem, it now also worked after deleting the .classpath file again. Given the mercurial nature of the problem, one can thus not be sure if this actually had an effect, or if the extension was just having a good day all along.

[ryeleo]

It seems this is closed, but I am facing this issue still. I am using:

Visual Studio Code version: 1.82.0-insider
Java extension version: 1.22.1
JDK: openjdk 17.0.8.1 2023-08-24

[gardner]

@ryeleo you can leave a review at https://marketplace.visualstudio.com/items?itemName=redhat.java

Please consider leaving a comment to describe your star rating.

[ascertrobw]

It seems this is closed, but I am facing this issue still. I am using:

Visual Studio Code version: 1.82.0-insider Java extension version: 1.22.1 JDK: openjdk 17.0.8.1 2023-08-24

Curious what Gradle version you are using?

I've just got my main build up to Gradle 8.3 in the hope I'd be able to work around this - I spotted a note in Gradle 8.1 along the lines that the buildship/eclipse outputDir could now be explicitly configured. I literally have not been able to use vscode for the past 2 years or more due to this issue. Be great to be able to use it again if it's sorted. NetBeans is OK but there are times where I'd like to be able to use vscode for java project work.

[fbricon]

You guys can try the vscode-gradle extension with "java.gradle.buildServer.enabled":"on". This contributes a new approach to Gradle support to vscode-java, that doesn't rely on Buildship, but delegates the build to the Gradle daemon instead. Doesn't generate a bin/ directory

[ascertrobw]

You guys can try the vscode-gradle extension with "java.gradle.buildServer.enabled":"on". This contributes a new approach to Gradle support to vscode-java, that doesn't rely on Buildship, but delegates the build to the Gradle daemon instead. Doesn't generate a bin/ directory

That is very good to know - will give it a try

[ascertrobw]

try the vscode-gradle extension with "java.gradle.buildServer.enabled":"on"

Sorry - dumb Q - where would I set this? Not seeing it as an obvious setting on the RH pack

[fbricon]

VSCode project or user settings.json

[ascertrobw]

Thanks. Strange, but that was what I'd tried - but on initially opening a folder with a gradle project in it I am still getting all the ./bin folders automatically created. So it doesn't look to be avoiding buildship for some reason. Am on latest (pre-release) versions of the java extension pack and gradle extension.

[fbricon]

The build server won't touch already imported projects. Try the Java: Clean the Java Language Server Workspace command, to prune existing import state

[ascertrobw]

Will try that - but not sure it's the cause. This was a brand new clean project, cloned fresh from our repos. So there should have been no pre-existing project. Moment I opened it the bin folders started appearing. Suspect I have some other setting/extension wrong or missing.

Edit - nope. Moment I open even a new project the ./bin cruft starts appearing. Ah well. Was worth a try, but it's gonna be back to Netbeans for me here I suspect. Not worth the pain. Still no clear way to add Java and Gradle support without folder pollution,

[RolKau]

@ascertrobw
What happens if you clone the same project into a new directory and add the content below into a file called .classpath at the root project directory before you open it in VSCode:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-17"/>
    <classpathentry kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>
</classpath>

[ascertrobw]

Will have to make some time to try that next week

@ascertrobw What happens if you clone the same project into a new directory and add the content below into a file called .classpath at the root project directory before you open it in VSCode:

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-17"/>
    <classpathentry kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>
</classpath>

Will see if I can make some time to try that next week - I presume that'll also work for Java 11? That's still our base build platform.

[RolKau]

I presume that'll also work for Java 11?

My condolences! In that case you replace JavaSE-17 with JavaSE-11 at the end of the third line.

[jhirn]

You guys can try the vscode-gradle extension with "java.gradle.buildServer.enabled":"on". This contributes a new approach to Gradle support to vscode-java, that doesn't rely on Buildship, but delegates the build to the Gradle daemon instead. Doesn't generate a bin/ directory

Hey @fbricon!. This actually worked after running Java: Clean the Java Language Server Workspace. I'm not sure if there are other drawbacks to this but one thing I'm trying to get is classes in build to be updated on save for hot reload in a Spring Boot app. I am working around this now by running gradle -t build in a separate window, but it would be nice if VSCode were compiling these on save and updating build/ to trigger a server reload. Is there some other setting I need to enable this?

[fbricon]

@jhirn no idea. Please ask on https://github.com/microsoft/vscode-gradle/issues

[adamsmd]

Here is a fix that works for me to prevent bin folders from automatically appearing: change java.autobuild.enabled to false.

(I don't know if bin folders will still appear if I manually build through VSCode, but at least it doesn't automatically appear just because I opened the editor.)

In the settings UI, this setting can be found under Extensions: Language Support for Java(TM) by Red Hat and is called Java > AutoBuild: Enabled. Note that it can be set at either the user or the workspace level, depending on what you want.

[djkeh]

Here is a fix that works for me to prevent bin folders from automatically appearing: change java.autobuild.enabled to false.

(I don't know if bin folders will still appear if I manually build through VSCode, but at least it doesn't automatically appear just because I opened the editor.)

In the settings UI, this setting can be found under Extensions: Language Support for Java(TM) by Red Hat and is called Java > AutoBuild: Enabled. Note that it can be set at either the user or the workspace level, depending on what you want.

This perfectly worked for me. I've been suffering for more than a couple of years not even knowing who's doing it. Many thanks @adamsmd !