dependency with com.sun.java.tools causes building error

I have a Maven project that uses JDK 1.8. If I add a dependency, such as net.openhft.lang, containing com.sun.java.tools (without specifying the version) to this project, the language server will generate an error "Missing artifact com.sun.java:tools🫙17.0.6", indicating that it cannot compile.
However, if I compile the project directly using mvn package, there are no errors. I use mvn dependency:tree to find that the version of com.sun.java.tools is just same as my JDK version installed and specified in the system (1.8.0_151).
It seems that the compilation behavior of the language server is different from directly using Maven, as it tries to look for version 17.0.6 (the JDK version embedded in the language server), instead of using version 1.8 in my system.

Environment

• Operating System: MacOS 11.4
• JDK version: 1.8.0_151 (Installed in /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home)
• Visual Studio Code version: 1.76.2
• Java extension version: v1.16.0

Steps To Reproduce

1. Create a Maven project with pom.xml
2. Add a dependency that requires com.sun.java.tools, such as net.openhft.lang (6.6.11 here), into dependencies in pom.xml
3. Wait for Language Support for Java to reload the project.

sample project: https://github.com/straywarrior/issue_samples/tree/main/vscode-java/maven-test-project
logs:

!ENTRY org.eclipse.jdt.ls.core 4 0 2023-04-06 15:05:37.733
!MESSAGE Error occured while building workspace. Details: 
 message: The container 'Maven Dependencies' references non existing library '/Users/XXX/.m2/repository/com/sun/java/tools/17.0.6/tools-17.0.6.jar'; code: 964; resource: /Users/XXX/maven-test-project;
 message: The project cannot be built until build path errors are resolved; code: 0; resource: /Users/XXX/maven-test-project;
 message: Missing artifact com.sun.java:tools:jar:17.0.6; code: 0; resource: /Users/XXX/maven-test-project/pom.xml; line: 4

Current Result

Language server returns error: Missing artifact com.sun.java:tools🫙17.0.6

Expected Result

No error should occur.

Additional Informations

mvn dependency:tree output:

[INFO] com.straywarrior:maven-test-project:jar:1.0
[INFO] \- net.openhft:lang:jar:6.6.11:compile
[INFO]    +- org.ow2.asm:asm:jar:5.0.3:compile
[INFO]    +- org.slf4j:slf4j-api:jar:1.7.6:compile
[INFO]    +- com.sun.java:tools:jar:1.8.0_151:system
[INFO]    +- net.openhft:compiler:jar:2.2.0:compile
[INFO]    |  +- (org.slf4j:slf4j-api:jar:1.7.6:compile - omitted for duplicate)
[INFO]    |  +- (com.sun.java:tools:jar:1.8.0_151:system - omitted for duplicate)
[INFO]    |  \- org.kohsuke.jetbrains:annotations:jar:9.0:compile
[INFO]    \- org.xerial.snappy:snappy-java:jar:1.1.1.6:compile

VSCode settings.json

    "java.configuration.runtimes": [
        {
            "name": "JavaSE-1.8",
            "path": "/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home",
            "default": true
        }
    ]

Start with the linked sample Maven project and reproduce the dependency resolution using the listed JDK 1.8 runtime and VS Code settings. Read the logged JDT LS build-path error and compare its handling of com.sun.java:tools with mvn dependency:tree. Done means the sample project reloads without a missing-artifact or build-path error.