You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Open any kind of project, even non-java ones (mixed), click on any .java file
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:
I use docker.
I don't use vscode for java, I use it for other parts of the project.
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.
The generated files are useless.
This extra compilation step burdens battery life and SSD wear.
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)!
Reacted by Nikhil Jamkhande, Mark Vilrokx, Jonathan Islas, Aaron Bloom, Joe Klauza, Rome Li, Nik Everett, dotc, Dean Iverson, Roy Wang and 84 more
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.
Reacted by maxi.wu, Hugh Williams, Keith Baker, jtdevos, Florent, Zhang Lei, Marco Lackovic, Alex Morozov, Ivan Staroselskiy, fanjieqi and 29 more
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.
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
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.
Reacted by Adam Cohen, Yiliang Wan and Thiago Ruiz
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"
Reacted by maxi.wu, A S, David Woodward and Nicholas Pate
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.
Wait the Java Language Server is ready. (:thumbsup: appears at the right bottom status bar)
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.
Reacted by Unichron, maxi.wu, Bohni, A S, Mayank Raj, Alex Morozov, Mahdi Hosseini, Manoj Baishya, Tony Soloveyv, Srijan Mukherjee and 1 more
@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:
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?
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.
Reacted by Marco Lackovic, Tom Sparrow, Uno Kim, Tony Soloveyv, Y, Nayuta Taga, Bodo Graumann, Miguel Carvalho, Khoi Pham Minh and José María García
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 !
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?
this saved me as well. took hours to find work-around way.
Activity
daliborfilus commentedon Sep 11, 2018
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 commentedon Oct 11, 2018
@Eskibear please take a look as a part of the effort of handling temp files.
nik9000 commentedon Oct 19, 2018
I've been using this extension for about 9 months full time. A week or two ago these
bindirectories 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 thesebindirectories 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 commentedon Oct 19, 2018
I suspect me seeing this issue late might have something to do with not upgrading very quickly. I'm not sure though.
tonny008 commentedon Dec 12, 2018
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 commentedon Dec 29, 2018
I solved this issue on Ubuntu by editing the
.classpathXML file, replacing allbin/withbuild/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 thesrc/folder to thebin/folder upon saving. Oddly enough, after changing the.classpathfile, it copies the folder structure and no Kotlin source files intobuild/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,.projectfiles and.settingsfolder, and also pollute thebin/folder, and I am running the latest extension version. Even while the.classpathfile was present and unmodified, it would still pollute the bin folder. As described previously, I edited the.classpathfile in an attempt to make it pollute a different folder, and it worked.ckuai commentedon Feb 11, 2019
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 commentedon Apr 9, 2019
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.
testforstephen commentedon May 7, 2019
Reproduced the issue.
.classpathfile, then a newbinfolder 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
binas 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 commentedon May 20, 2019
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 commentedon Jun 18, 2019
Any update on this issue? Seems like my scons build rules are finding multiple copies of themselves and conflicting!
dsculptor commentedon Jun 24, 2019
I think this is a serious issue, and unfortunately the only solution for me right now is to use idea. sorry VSCODE-JAVA
keefbaker commentedon Jun 27, 2019
Agreed. Until this stops, this extension is basically unusable.
janbodnar commentedon Jul 8, 2019
This is gross. Removed the extension immediately. Not only it makes Java for Code unusable, it also ruins the reputation of the Code.
77 remaining items
ascertrobw commentedon Sep 22, 2023
Will have to make some time to try that next week
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 commentedon Sep 22, 2023
My condolences! In that case you replace
JavaSE-17withJavaSE-11at the end of the third line.jhirn commentedon Oct 11, 2023
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 runninggradle -t buildin a separate window, but it would be nice if VSCode were compiling these on save and updatingbuild/to trigger a server reload. Is there some other setting I need to enable this?fbricon commentedon Oct 12, 2023
@jhirn no idea. Please ask on https://github.com/microsoft/vscode-gradle/issues
Move bin/ files to scripts/
adamsmd commentedon Nov 19, 2024
Here is a fix that works for me to prevent
binfolders from automatically appearing: changejava.autobuild.enabledtofalse.(I don't know if
binfolders 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 Hatand is calledJava > AutoBuild: Enabled. Note that it can be set at either the user or the workspace level, depending on what you want.djkeh commentedon Jan 17, 2025
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 !
einarjohnson commentedon Mar 18, 2025
has this issue ever been fixed properly in vscode? facing the same issue here using Gradle in a multi-project setup. Super annoying.
eleses commentedon Jun 26, 2025
I don't understand how this was "fixed" in 2020. It still does this nonsense for me in 2025.
Copies everything in source dir but the java files to java.project.outputPath. The java files it compiles though.
eleses commentedon Jun 26, 2025
And what happens you click "Rebuild all"?! Full copy of everything but the java files to the outputPath.
Nhangg commentedon Aug 8, 2025
this saved me as well. took hours to find work-around way.
Remove extension artifacts (#944)
slowhigh commentedon Jan 15, 2026
The best approach is to create the file below and configure it as shown to hide the folders.
File path:
.vscode/settings.json{ "files.exclude": { "**/build": true, "**/bin": true } }awecz commentedon Mar 4, 2026
This nonsense is still present in 2026.
lsc4719 commentedon Nov 5, 2026