[GR-68951] Link fixes

ban-mi · ban-mi · commit d18bce1b8949 · 2025-08-27T00:32:57.000Z
PullRequest: graal/21929
diff --git a/docs/getting-started/oci/cloud-shell.md b/docs/getting-started/oci/cloud-shell.md
@@ -112,7 +112,5 @@ Thus, you can use Oracle GraalVM in OCI Cloud Shell to build and test simple Jav
 
 ### Related Documentation
 
-- [Java Hello World with Oracle GraalVM in OCI Cloud Shell](https://github.com/graalvm/graalvm-demos/blob/master/java-hello-world-maven/README-Cloud-Shell.md)
-- [Micronaut Hello World REST App with Oracle GraalVM in OCI Cloud Shell](https://github.com/graalvm/graalvm-demos/blob/master/micronaut-hello-rest-maven/README-Cloud-Shell.md)
-- [Spring Boot Microservice with Oracle GraalVM in OCI Cloud Shell](https://github.com/graalvm/graalvm-demos/blob/master/spring-native-image/README-Cloud-Shell.md)
+- [Java Hello World with Oracle GraalVM in OCI Cloud Shell](https://github.com/graalvm/graalvm-demos/blob/master/native-image/clouds/native-oci-cloud-shell/README-Cloud-Shell.md)
 - [Oracle GraalVM in OCI Code Editor](code-editor.md)
diff --git a/docs/reference-manual/java/Operations.md b/docs/reference-manual/java/Operations.md
@@ -101,7 +101,7 @@ In this example, you would add the following options to your command line:
 
 These options are described in more detail in the [compiler debugging documentation](https://github.com/oracle/graal/blob/master/compiler/docs/Debugging.md){:target="_blank"}.
 In brief, these options tell the Graal JIT compiler to capture snapshots of its state at verbosity level 2 while compiling any method named `matchComplexExpressions` in a class with a simple name of `NodeLIRBuilder`.
-The complete format of the `MethodFilter` option is described in [MethodFilterHelp.txt](https://github.com/oracle/graal/blob/master/compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/debug/doc-files/MethodFilterHelp.txt){:target="_blank"}.
+The complete format of the `MethodFilter` option is described in [MethodFilterHelp.txt](https://github.com/oracle/graal/blob/vm-24.2.2/compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/debug/doc-files/MethodFilterHelp.txt){:target="_blank"}.
 
 Quite often, the crash location does not exist directly in the problematic method mentioned in the crash log but comes from an inlined method.
 
diff --git a/docs/reference-manual/native-image/BuildConfiguration.md b/docs/reference-manual/native-image/BuildConfiguration.md
@@ -69,7 +69,7 @@ Executing [
 ]
 ```
 
-Typical examples of configurations that use a configuration from _META-INF/native-image_ can be found in [Native Image configuration examples](https://github.com/graalvm/graalvm-demos/tree/master/native-image-configure-examples).
+Typical examples of configurations that use a configuration from _META-INF/native-image_ can be found in [Native Image configuration examples](https://github.com/graalvm/graalvm-demos/blob/master/README.md#configure).
 
 ## Configuration File Format
 
diff --git a/docs/reference-manual/native-image/BuildReport.md b/docs/reference-manual/native-image/BuildReport.md
@@ -29,7 +29,7 @@ Here you will learn how to generate a Build Report and how to use each report se
 
 ## Report Generation
 
-A simple HelloWorld Micronaut application (available in the [GraalVM Demos repository](https://github.com/graalvm/graalvm-demos/tree/master/micronaut-hello-rest-maven)) is used to demonstrate Build Report generation and its structure.
+A simple HelloWorld Micronaut application (available in the [GraalVM Demos repository](https://github.com/graalvm/graalvm-demos/tree/master/native-image/microservices/micronaut-hello-rest-maven)) is used to demonstrate Build Report generation and its structure.
 
 A Build Report can simply be generated using the `--emit` option when running the `native-image` command:
 
diff --git a/docs/reference-manual/native-image/ReachabilityMetadata.md b/docs/reference-manual/native-image/ReachabilityMetadata.md
@@ -23,8 +23,8 @@ Providing the builder with correct and exhaustive reachability metadata guarante
 
 Metadata can be provided to the `native-image` builder in the following ways:
 - By [computing metadata in code](#computing-metadata-in-code) [when the native binary is built](NativeImageBasics.md#image-build-time-vs-image-run-time) and storing required elements into the [initial heap of the native binary](NativeImageBasics.md#native-image-heap).
-- By [providing the _reachability-metadata.json_ file(s)](#specifying-metadata-with-json) stored in the _META-INF/native-image/\<group.Id>\/\<artifactId>\/_ directory on the classpath. For more information about how to collect metadata for your application automatically, see [Collecting Metadata Automatically](AutomaticMetadataCollection.md).
-- For more advanced use cases, where classpath scanning or build-time initialization is needed, by using the [public API](#public-api).
+- By [providing the _reachability-metadata.json_ file(s)](#specifying-metadata-with-json) stored in the _META-INF/native-image/&lt;group.Id&gt;/&lt;artifactId&gt;/_ directory on the classpath. For more information about how to collect metadata for your application automatically, see [Collecting Metadata Automatically](AutomaticMetadataCollection.md).
+- For more advanced use cases, where classpath scanning or build-time initialization is needed.
 
 > Note: Native Image is migrating to the more user-friendly implementation of reachability metadata that shows problems early on and allows easy debugging.
 >
diff --git a/docs/reference-manual/native-image/WorkshopsAndLabs.md b/docs/reference-manual/native-image/WorkshopsAndLabs.md
@@ -20,10 +20,7 @@ The following labs are available:
 - [GraalVM, Reflection and Native Image](https://luna.oracle.com/lab/5fde71fb-8044-4c82-aa1c-3f2e5771caed): This lab shows how to preconfigure the `native-image` builder when reflection is used, and make your Java application compatible with ahead-of-time compilation using Native Image.
 - [GraalVM Native Image, Spring and Containerisation](https://luna.oracle.com/lab/fdfd090d-e52c-4481-a8de-dccecdca7d68): This lab shows you how to package a Spring Boot application into a native executable; containerise it; shrink the footprint even more by creating small a Distroless container Image.
 - [Optimize Cloud Native Java Apps with Oracle GraalVM PGO](https://luna.oracle.com/lab/3f0b7c86-6105-4b7a-9a3b-eb73b251a1aa): This lab shows how to run a Java Microbenchmark Harness (JMH) benchmark as a native executable, built with GraalVM Native Image, and then optimize it for higher throughput using Profile-Guided Optimization (PGO).
-- [OCI MySQL, Vault, Micronaut, GraalVM Native Image](https://luna.oracle.com/lab/a78388fd-c15f-48b4-96aa-5e4716ae236c): In this lab, you will learn how to build a portable cloud-native Java application with Micronaut, GraalVM Native Image and MySQL Database service, and Secrets in Vault on Oracle Cloud Infrastructure.
 - [GraalVM Native Build Tools, for Maven](https://luna.oracle.com/lab/e5af592b-3365-45ce-b964-6fd409e5c76f): This lab shows you how to use the GraalVM Native Build Tools to easily build a native executable of your application using Maven. It is aimed at developers with the knowledge of Java.
-- [Build Cloud Native Java Applications with Micronaut and GraalVM Native Image](https://luna.oracle.com/lab/e329af0f-504e-4eb0-8804-2dd6b10076c9): The workshop features several labs that walk you through the steps to get going with Micronaut, GraalVM, and Oracle Cloud Infrastructure services.
-- [GraalVM Native Image Bootcamp](https://luna.oracle.com/lab/d642bb4a-0340-4dab-a4cf-c5ef35795884): This workshop covers how GraalVM Native Image works, what it can do, when to use it, and how to tune and debug applications. You will also look at containerisation options and deployment to cloud platforms including Oracle Cloud Infrastructure.
 
 ## Workshops
 
diff --git a/docs/reference-manual/native-image/guides/build-static-and-mostly-static-executable.md b/docs/reference-manual/native-image/guides/build-static-and-mostly-static-executable.md
@@ -139,5 +139,5 @@ In both cases, choosing the base container image generally depends on your nativ
 
 ### Related Documentation
 
-* [Tiny Java Containers](https://github.com/graalvm/graalvm-demos/tree/master/tiny-java-containers) demo shows how a simple Java application and a simple web server can be compiled to produce very small Docker container images using various lightweight base images.
-* [GraalVM Native Image, Spring and Containerisation](https://luna.oracle.com/lab/fdfd090d-e52c-4481-a8de-dccecdca7d68) interactive lab to build a mostly static executable of a Spring Boot application.
+* [Tiny Java Containers](https://github.com/graalvm/graalvm-demos/tree/master/native-image/tiny-java-containers) demo shows how a simple Java application and a simple web server can be compiled to produce very small Docker container images using various lightweight base images.
+* [GraalVM Native Image, Spring and Containerization](https://luna.oracle.com/lab/fdfd090d-e52c-4481-a8de-dccecdca7d68) interactive lab to build a mostly static executable of a Spring Boot application.
diff --git a/docs/reference-manual/native-image/guides/guides.md b/docs/reference-manual/native-image/guides/guides.md
@@ -36,8 +36,8 @@ Here you will learn how to:
 - [Optimize Size of a Native Executable using Build Reports](optimize-native-executable-size-using-build-report.md)
 - [Optimize Memory Footprint of a Native Executable](optimize-memory-footprint.md)
 - [Specify Class Initialization Explicitly](specify-class-initialization.md)
-- [Use Gradle to Build a Native Executable from a Java Application](https://graalvm.github.io/native-build-tools/latest/gradle-plugin-quickstart.html)
-- [Use Maven to Build a Native Executable from a Java Application](https://graalvm.github.io/native-build-tools/latest/maven-plugin-quickstart.html)
+- [Use Gradle to Build a Native Executable from a Java Application](https://graalvm.github.io/native-build-tools/latest/end-to-end-gradle-guide.html)
+- [Use Maven to Build a Native Executable from a Java Application](https://graalvm.github.io/native-build-tools/latest/end-to-end-maven-guide.html)
 
 ## Microservices Frameworks
 
diff --git a/docs/reference-manual/native-image/guides/include-reachability-metadata-gradle.md b/docs/reference-manual/native-image/guides/include-reachability-metadata-gradle.md
@@ -17,7 +17,7 @@ Depending on your application dependencies, there are three ways to provide the
 
 1. [Using the GraalVM Reachability Metadata Repository](#build-a-native-executable-using-the-graalvm-reachability-metadata-repository)
 2. [Using the Tracing Agent](#build-a-native-executable-with-the-tracing-agent)
-3. [Autodetecting](https://graalvm.github.io/native-build-tools/latest/gradle-plugin-quickstart.html#build-a-native-executable-with-resources-autodetection) (if the required resources are directly available on the class path, in the _src/main/resources/_ directory)
+3. [Autodetecting](https://graalvm.github.io/native-build-tools/latest/gradle-plugin.html#resources-autodetecting) (if the required resources are directly available on the class path, in the _src/main/resources/_ directory)
 
 This guide demonstrates how to build a native executable using the [GraalVM Reachability Metadata Repository](https://github.com/oracle/graalvm-reachability-metadata), and with the [Tracing Agent](https://graalvm.github.io/native-build-tools/latest/gradle-plugin.html#agent-support).
 The goal of this guide is to illustrate the difference between the two approaches, and demonstrate how the use of reachability metadata can simplify your development tasks.
diff --git a/docs/reference-manual/native-image/guides/include-reachability-metadata-maven.md b/docs/reference-manual/native-image/guides/include-reachability-metadata-maven.md
@@ -17,7 +17,7 @@ Depending on your application dependencies, there are three ways to provide the
 
 1. [Using the GraalVM Reachability Metadata Repository](#build-a-native-executable-using-the-graalvm-reachability-metadata-repository)
 2. [Using the Tracing Agent](#build-a-native-executable-with-the-tracing-agent)
-3. [Autodetecting](https://graalvm.github.io/native-build-tools/latest/gradle-plugin-quickstart.html#build-a-native-executable-with-resources-autodetection) (if the required resources are directly available on the class path, in the _src/main/resources/_ directory)
+3. [Autodetecting](https://graalvm.github.io/native-build-tools/latest/gradle-plugin.html#resources-autodetecting) (if the required resources are directly available on the class path, in the _src/main/resources/_ directory)
 
 This guide demonstrates how to build a native executable using the [GraalVM Reachability Metadata Repository](https://github.com/oracle/graalvm-reachability-metadata), and with the [Tracing Agent](https://graalvm.github.io/native-build-tools/latest/gradle-plugin.html#agent-support).
 The goal of this guide is to illustrate the difference between the two approaches, and demonstrate how the use of reachability metadata can simplify your development tasks.
diff --git a/docs/reference-manual/native-image/guides/optimize-native-executable-with-pgo.md b/docs/reference-manual/native-image/guides/optimize-native-executable-with-pgo.md
@@ -49,7 +49,8 @@ Make sure you have installed a GraalVM JDK.
 The easiest way to get started is with [SDKMAN!](https://sdkman.io/jdks#graal).
 For other installation options, visit the [Downloads section](https://www.graalvm.org/downloads/).
 
-1.  Save [the following code](https://github.com/graalvm/graalvm-demos/blob/master/streams/Streams.java) to the file named _Streams.java_:
+1.  Save [the following code](https://github.com/graalvm/graalvm-demos/blob/master/native-image/optimize-with-pgo/Streams.java) to the file named _Streams.java_:
+
     ```java
     import java.util.Arrays;
     import java.util.Random;
diff --git a/docs/security/SBOM.md b/docs/security/SBOM.md
@@ -174,7 +174,7 @@ This information can be useful for:
 * **Advanced vulnerability scanning:** When the affected classes or methods of a vulnerability are published as part of a CVE, the class-level metadata can be checked to determine if a native executable with the affected SBOM component is actually vulnerable, thereby reducing the false positive rate of vulnerability scanning.
 * **Understanding image contents:** Quickly browse and search the class-level metadata to examine what is included in the native executable.
 
-> Including class-level metadata increases the SBOM size substantially. For this [Micronaut Hello World Rest](https://github.com/graalvm/graalvm-demos/tree/master/micronaut-hello-rest-maven) application, the SBOM size is 1.1 MB when embedded, and 13.7 MB when exported. The SBOM without class-level metadata is 3.5 kB when embedded, and 64 kB when exported. The size of the native image without an embedded SBOM is around 52 MB.
+> Including class-level metadata increases the SBOM size substantially. For this [Micronaut Hello World Rest](https://github.com/graalvm/graalvm-demos/tree/master/native-image/microservices/micronaut-hello-rest-maven) application, the SBOM size is 1.1 MB when embedded, and 13.7 MB when exported. The SBOM without class-level metadata is 3.5 kB when embedded, and 64 kB when exported. The size of the native image without an embedded SBOM is around 52 MB.
 
 Note that including class-level metadata is not supported by [Syft](#syft), as the nested components field containing this metadata is removed from the extracted SBOM.
 This limitation affects only metadata visibility in extracted SBOMs; it does not impact vulnerability scanning functionality.
diff --git a/docs/tools/code-coverage.md b/docs/tools/code-coverage.md
@@ -222,7 +222,6 @@ $JAVA_HOME/bin/npm install express
 ```
 
 3. Launch Visual Studio Code and install a code coverage plugin that supports _lcov_.
-The [Code Coverage Highlighter](https://marketplace.visualstudio.com/items?itemName=brainfit.vscode-coverage-highlighter) is used for this example, but other plugins should work similarly.
 
 4. Run the _nodeapp.js_ file with coverage enabled and configured:
 ```shell
@@ -231,7 +230,7 @@ $JAVA_HOME/bin/node --coverage --coverage.Output=lcov \
 nodeapp.js
 ```
 
-Note that the Code Coverage Highlighter plugin looks for the `lcov.info` file in the `coverage` directory by default, so direct the output of the code coverage tool there.
+Note that the plugin may look for the _lcov.info_ file in the _coverage_ directory by default, so direct the output of the code coverage tool there.
 
 5. Visit [localhost:3000/](http://localhost:3000/) in your browser, then visit [localhost:3000/shutdown](http://localhost:3000/shutdown) to close the app.
 
diff --git a/docs/tools/dap.md b/docs/tools/dap.md
@@ -76,8 +76,6 @@ code .
 
 8&#46; Start debugging (F5).
 
-The other approach is to use VS Code with the GraalVM extension installed.
-Follow the steps described in [Node.js and JavaScript Debugging](https://marketplace.visualstudio.com/items?itemName=oracle-labs-graalvm.graalvm#javascript-and-node.js-debugging), and launch the application being debugged directly from VS Code.
 When debugging a guest language application from VS Code, a user can choose a protocol to use by setting the protocol attribute in the corresponding debug configuration to either `chromeDevTools` or `debugAdapter`.
 To connect to the open DAP port in this scenario, the content of the _launch.json_ should be:
 
diff --git a/docs/tools/lsp.md b/docs/tools/lsp.md
@@ -26,5 +26,3 @@ The GraalVM Language Server itself does not provide the static data usually gath
 Instead, the Language Server was designed to provide the accurate dynamic data gathered from the application runtime.
 
 However, the Language Server could delegate to the existing language servers written specially for the particular languages (using the `--lsp.Delegates` launcher option) and merge the static data returned from these servers with its own dynamic data to a single result.
-
-For more information about the GraalVM Language Server and its usage in GraalVM Visual Studio Code Extension, see [Visual Studio Code Marketplace documentation](https://marketplace.visualstudio.com/items?itemName=oracle-labs-graalvm.graalvm).

Original file line number	Diff line number	Diff line change
`@@ -69,7 +69,7 @@ Executing [`
`69`	`69`	`]`
`70`	`70`	```
`71`	`71`
`72`		`-Typical examples of configurations that use a configuration from _META-INF/native-image_ can be found in [Native Image configuration examples](https://github.com/graalvm/graalvm-demos/tree/master/native-image-configure-examples).`
	`72`	`+Typical examples of configurations that use a configuration from _META-INF/native-image_ can be found in [Native Image configuration examples](https://github.com/graalvm/graalvm-demos/blob/master/README.md#configure).`
`73`	`73`
`74`	`74`	`## Configuration File Format`
`75`	`75`
Original file line number	Diff line number	Diff line change
`@@ -23,8 +23,8 @@ Providing the builder with correct and exhaustive reachability metadata guarante`
`23`	`23`
`24`	`24`	Metadata can be provided to the `native-image` builder in the following ways:
`25`	`25`	`- By [computing metadata in code](#computing-metadata-in-code) [when the native binary is built](NativeImageBasics.md#image-build-time-vs-image-run-time) and storing required elements into the [initial heap of the native binary](NativeImageBasics.md#native-image-heap).`
`26`		`-- By [providing the _reachability-metadata.json_ file(s)](#specifying-metadata-with-json) stored in the _META-INF/native-image/\<group.Id>\/\<artifactId>\/_ directory on the classpath. For more information about how to collect metadata for your application automatically, see [Collecting Metadata Automatically](AutomaticMetadataCollection.md).`
`27`		`-- For more advanced use cases, where classpath scanning or build-time initialization is needed, by using the [public API](#public-api).`
	`26`	`+- By [providing the _reachability-metadata.json_ file(s)](#specifying-metadata-with-json) stored in the _META-INF/native-image/<group.Id>/<artifactId>/_ directory on the classpath. For more information about how to collect metadata for your application automatically, see [Collecting Metadata Automatically](AutomaticMetadataCollection.md).`
	`27`	`+- For more advanced use cases, where classpath scanning or build-time initialization is needed.`
`28`	`28`
`29`	`29`	`> Note: Native Image is migrating to the more user-friendly implementation of reachability metadata that shows problems early on and allows easy debugging.`
`30`	`30`	`>`