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 the Win11 workflow by opening the Bazel project in VSCode with the POM dependency on libre-eval.jar, then run the reported bazel build command and inspect the Java language-server process for the file lock. Done means the dependent JAR can be rebuilt while VSCode remains open, without requiring the Eclipse-style manual refresh workaround.