Extension holds locks on JAR files referenced in POM.xml

I use bazel to compile/package my java project, but I have some bazel rules to build a pom.xml so eclipse can work with the project. I've been trying to switch to vscode-java, and one of the problems I'm having is that the language server seems to be holding a lock on my dependent JAR files, so that I can no longer rebuild with bazel. Eclipse does not have this problem.

Environment

• Operating System: Win11
• JDK version: 19
• Visual Studio Code version: Codium 1.85.1
• Java extension version: 1.28.1

Steps To Reproduce

• My bazel project references a dependent project named 're-eval', which produces a jar file named 'libre-eval.jar'. I run my bazel build command to build the dependent jars.
• I then generate a POM file that references that jar file in my bazel bin directory, using the system scope so that I can reference the direct path:

<dependency>
	<groupId>com.bazel.dependency</groupId>
	<artifactId>re-eval</artifactId>
	<version>1.0.0-bazel</version>
	<systemPath>D:\MyProj\.bazel/out/x64_windows-fastbuild/bin/external/re/re-eval/libre-eval.jar</systemPath>
	<scope>system</scope>
</dependency>

• Next I open VSCode to this project. The language server opens the project, everything loads fine.
• Finally I try to run my build again. Bazel can't rebuild that jar file because:

> bazel build //:project
INFO: Analyzed target //:project (81 packages loaded, 6098 targets configured).
INFO: Found 1 target...
ERROR: D:/bazel/y4yaxzuk/external/re/re-eval/BUILD:9:13: Building external/re/re-eval/libre-eval.jar (2 source files) failed: failed to delete output files before executing action: D:/bazel/y4yaxzuk/execroot/__main__/bazel-out/x64_windows-fastbuild/bin/external/re/re-eval/libre-eval.jar (Permission denied)
Target //:project failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 12.805s, Critical Path: 4.09s
INFO: 24 processes: 13 internal, 10 local, 1 worker.
FAILED: Build did NOT complete successfully

• The process that has a lock on this file is:

C:\apps\Java\jdk-19.0.1\bin\java --add-modules=ALL-SYSTEM --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.nio.fs=ALL-UNNAMED -Declipse.application=org.eclipse.jdt.ls.core.id1 -Dosgi.bundles.defaultStartLevel=4 -Declipse.product=org.eclipse.jdt.ls.core.product -Djava.import.generatesMetadataFilesAtProjectRoot=false -DDetectVMInstallationsJob.disabled=true -Dfile.encoding=utf8 -XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx1G -Xms100m -Xlog:disable -javaagent:c:\apps\Scoop\apps\vscodium\1.85.1.23348\data\extensions\redhat.java-1.28.1-win32-x64\lombok\lombok-1.18.31.jar -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=c:\apps\Scoop\apps\vscodium\1.85.1.23348\data\user-data\User\workspaceStorage\752d67d371268c29632f9f8dea706e20\redhat.java -Daether.dependencyCollector.impl=bf -jar C:\apps\Scoop\persist\vscodium\data\extensions\redhat.java-1.28.1-win32-x64\server\plugins\org.eclipse.equinox.launcher_1.6.700.v20231214-2017.jar -configuration c:\apps\Scoop\apps\vscodium\1.85.1.23348\data\user-data\User\globalStorage\redhat.java\1.28.1\config_win -data c:\apps\Scoop\apps\vscodium\1.85.1.23348\data\user-data\User\workspaceStorage\752d67d371268c29632f9f8dea706e20\redhat.java\jdt_ws --stdio

It seems that this process has a lock on all of the Jars defined in the pom.xml file according to Process Explorer. I've disabled the "Maven for Java" and "Project Manager for Java" extensions, and only have the "Language Support for Java" extension enabled.

Eclipse opens the same project with the same pom file and I can rebuild my project through bazel without having file locks - I do need to do a project refresh in Eclipse sometimes to get it to pick up API changes from those builds, so maybe this is just a fundamental difference between Eclipse (a bit more manual) and VSCode (a bit more automated). Are there any workarounds to this issue?

Reproduce el flujo de trabajo de Win11 abriendo el proyecto de Bazel en VSCode con la dependencia de POM en libre-eval.jar; después, ejecuta el comando bazel build indicado e inspecciona el proceso de Java language-server para detectar el bloqueo del archivo. Se considera terminado cuando el JAR dependiente puede volver a compilarse mientras VSCode permanece abierto, sin requerir la solución alternativa de actualización manual al estilo de Eclipse.