Migrate class references to full javadoc links

Update documentation to use `javadoc:...` macro for class and interface
references.

Migrated using https://github.com/philwebb/asciidoctor-javadoc-migration

See gh-41614

spring-boot-project/spring-boot-docs/src/docs/antora/modules/specification/pages/configuration-metadata/annotation-processor.adoc

@@ -1,7 +1,7 @@
 [[appendix.configuration-metadata.annotation-processor]]
 = Generating Your Own Metadata by Using the Annotation Processor
 
-You can easily generate your own configuration metadata file from items annotated with `@ConfigurationProperties` by using the `spring-boot-configuration-processor` jar.
+You can easily generate your own configuration metadata file from items annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] by using the `spring-boot-configuration-processor` jar.
 The jar includes a Java annotation processor which is invoked as your project is compiled.
 
 
@@ -73,14 +73,14 @@ If you are not using this attribute, and annotation processors are picked up by
 [[appendix.configuration-metadata.annotation-processor.automatic-metadata-generation]]
 == Automatic Metadata Generation
 
-The processor picks up both classes and methods that are annotated with `@ConfigurationProperties`.
+The processor picks up both classes and methods that are annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation].
 
-NOTE: Custom annotations that are meta-annotated with `@ConfigurationProperties` are not supported.
+NOTE: Custom annotations that are meta-annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] are not supported.
 
-If the class has a single parameterized constructor, one property is created per constructor parameter, unless the constructor is annotated with `@Autowired`.
-If the class has a constructor explicitly annotated with `@ConstructorBinding`, one property is created per constructor parameter for that constructor.
+If the class has a single parameterized constructor, one property is created per constructor parameter, unless the constructor is annotated with javadoc:org.springframework.beans.factory.annotation.Autowired[format=annotation].
+If the class has a constructor explicitly annotated with javadoc:org.springframework.boot.context.properties.bind.ConstructorBinding[format=annotation], one property is created per constructor parameter for that constructor.
 Otherwise, properties are discovered through the presence of standard getters and setters with special handling for collection and map types (that is detected even if only a getter is present).
-The annotation processor also supports the use of the `@lombok.Data`, `@lombok.Value`, `@lombok.Getter`, and `@lombok.Setter` lombok annotations.
+The annotation processor also supports the use of the javadoc:{url-lombok-javadoc}/lombok.Data[format=annotation], javadoc:{url-lombok-javadoc}/lombok.Value[format=annotation], javadoc:{url-lombok-javadoc}/lombok.Getter[format=annotation], and javadoc:{url-lombok-javadoc}/lombok.Setter[format=annotation] lombok annotations.
 
 Consider the following example:
 
@@ -89,9 +89,9 @@ include-code::MyServerProperties[]
 This exposes three properties where `my.server.name` has no default and `my.server.ip` and `my.server.port` defaults to `"127.0.0.1"` and `9797` respectively.
 The Javadoc on fields is used to populate the `description` attribute. For instance, the description of `my.server.ip` is "IP address to listen to.".
 
-NOTE: You should only use plain text with `@ConfigurationProperties` field Javadoc, since they are not processed before being added to the JSON.
+NOTE: You should only use plain text with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] field Javadoc, since they are not processed before being added to the JSON.
 
-If you use `@ConfigurationProperties` with record class then record components' descriptions should be provided via class-level Javadoc tag `@param` (there are no explicit instance fields in record classes to put regular field-level Javadocs on).
+If you use javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] with record class then record components' descriptions should be provided via class-level Javadoc tag `@param` (there are no explicit instance fields in record classes to put regular field-level Javadocs on).
 
 The annotation processor applies a number of heuristics to extract the default value from the source model.
 Default values have to be provided statically. In particular, do not refer to a constant defined in another class.
@@ -132,7 +132,7 @@ Consider the updated example:
 include-code::MyServerProperties[]
 
 The preceding example produces metadata information for `my.server.name`, `my.server.host.ip`, and `my.server.host.port` properties.
-You can use the `@NestedConfigurationProperty` annotation on a field to indicate that a regular (non-inner) class should be treated as if it were nested.
+You can use the javadoc:org.springframework.boot.context.properties.NestedConfigurationProperty[format=annotation] annotation on a field to indicate that a regular (non-inner) class should be treated as if it were nested.
 
 TIP: This has no effect on collections and maps, as those types are automatically identified, and a single metadata property is generated for each of them.
 
@@ -141,7 +141,7 @@ TIP: This has no effect on collections and maps, as those types are automaticall
 [[appendix.configuration-metadata.annotation-processor.adding-additional-metadata]]
 == Adding Additional Metadata
 
-Spring Boot's configuration file handling is quite flexible, and it is often the case that properties may exist that are not bound to a `@ConfigurationProperties` bean.
+Spring Boot's configuration file handling is quite flexible, and it is often the case that properties may exist that are not bound to a javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] bean.
 You may also need to tune some attributes of an existing key.
 To support such cases and let you provide custom "hints", the annotation processor automatically merges items from `META-INF/additional-spring-configuration-metadata.json` into the main metadata file.
 

spring-boot-project/spring-boot-docs/src/docs/antora/modules/specification/pages/configuration-metadata/format.adoc

@@ -104,8 +104,8 @@ The JSON object contained in the `groups` array can contain the attributes shown
 | `type`
 | String
 | The class name of the data type of the group.
-  For example, if the group were based on a class annotated with `@ConfigurationProperties`, the attribute would contain the fully qualified name of that class.
-  If it were based on a `@Bean` method, it would be the return type of that method.
+  For example, if the group were based on a class annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation], the attribute would contain the fully qualified name of that class.
+  If it were based on a javadoc:org.springframework.context.annotation.Bean[format=annotation] method, it would be the return type of that method.
   If the type is not known, the attribute may be omitted.
 
 | `description`
@@ -118,12 +118,12 @@ The JSON object contained in the `groups` array can contain the attributes shown
 | `sourceType`
 | String
 | The class name of the source that contributed this group.
-  For example, if the group were based on a `@Bean` method annotated with `@ConfigurationProperties`, this attribute would contain the fully qualified name of the `@Configuration` class that contains the method.
+  For example, if the group were based on a javadoc:org.springframework.context.annotation.Bean[format=annotation] method annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation], this attribute would contain the fully qualified name of the javadoc:org.springframework.context.annotation.Configuration[format=annotation] class that contains the method.
   If the source type is not known, the attribute may be omitted.
 
 | `sourceMethod`
 | String
-| The full name of the method (include parenthesis and argument types) that contributed this group (for example, the name of a `@ConfigurationProperties` annotated `@Bean` method).
+| The full name of the method (include parenthesis and argument types) that contributed this group (for example, the name of a javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] annotated javadoc:org.springframework.context.annotation.Bean[format=annotation] method).
   If the source method is not known, it may be omitted.
 |===
 
@@ -146,10 +146,10 @@ The JSON object contained in the `properties` array can contain the attributes d
 
 | `type`
 | String
-| The full signature of the data type of the property (for example, `java.lang.String`) but also a full generic type (such as `java.util.Map<java.lang.String,com.example.MyEnum>`).
+| The full signature of the data type of the property (for example, javadoc:java.lang.String[]) but also a full generic type (such as `java.util.Map<java.lang.String,com.example.MyEnum>`).
   You can use this attribute to guide the user as to the types of values that they can enter.
-  For consistency, the type of a primitive is specified by using its wrapper counterpart (for example, `boolean` becomes `java.lang.Boolean`).
-  Note that this class may be a complex type that gets converted from a `String` as values are bound.
+  For consistency, the type of a primitive is specified by using its wrapper counterpart (for example, `boolean` becomes javadoc:java.lang.Boolean[]).
+  Note that this class may be a complex type that gets converted from a javadoc:java.lang.String[] as values are bound.
   If the type is not known, it may be omitted.
 
 | `description`
@@ -162,7 +162,7 @@ The JSON object contained in the `properties` array can contain the attributes d
 | `sourceType`
 | String
 | The class name of the source that contributed this property.
-  For example, if the property were from a class annotated with `@ConfigurationProperties`, this attribute would contain the fully qualified name of that class.
+  For example, if the property were from a class annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation], this attribute would contain the fully qualified name of that class.
   If the source type is unknown, it may be omitted.
 
 | `defaultValue`
@@ -212,7 +212,7 @@ NOTE: Prior to Spring Boot 1.3, a single `deprecated` boolean attribute can be u
 This is still supported in a deprecated fashion and should no longer be used.
 If no reason and replacement are available, an empty `deprecation` object should be set.
 
-Deprecation can also be specified declaratively in code by adding the `@DeprecatedConfigurationProperty` annotation to the getter exposing the deprecated property.
+Deprecation can also be specified declaratively in code by adding the javadoc:org.springframework.boot.context.properties.DeprecatedConfigurationProperty[format=annotation] annotation to the getter exposing the deprecated property.
 For instance, assume that the `my.app.target` property was confusing and was renamed to `my.app.name`.
 The following example shows how to handle that situation:
 

spring-boot-project/spring-boot-docs/src/docs/antora/modules/specification/pages/configuration-metadata/index.adoc

@@ -5,5 +5,5 @@
 Spring Boot jars include metadata files that provide details of all supported configuration properties.
 The files are designed to let IDE developers offer contextual help and "`code completion`" as users are working with `application.properties` or `application.yaml` files.
 
-The majority of the metadata file is generated automatically at compile time by processing all items annotated with `@ConfigurationProperties`.
+The majority of the metadata file is generated automatically at compile time by processing all items annotated with javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation].
 However, it is possible to xref:configuration-metadata/annotation-processor.adoc#appendix.configuration-metadata.annotation-processor.adding-additional-metadata[write part of the metadata manually] for corner cases or more advanced use cases.

spring-boot-project/spring-boot-docs/src/docs/antora/modules/specification/pages/configuration-metadata/manual-hints.adoc

@@ -15,10 +15,10 @@ The `name` attribute of each hint refers to the `name` of a property.
 In the xref:configuration-metadata/format.adoc[initial example shown earlier], we provide five values for the `spring.jpa.hibernate.ddl-auto` property: `none`, `validate`, `update`, `create`, and `create-drop`.
 Each value may have a description as well.
 
-If your property is of type `java.util.Map`, you can provide hints for both the keys and the values (but not for the map itself).
+If your property is of type javadoc:java.util.Map[], you can provide hints for both the keys and the values (but not for the map itself).
 The special `.keys` and `.values` suffixes must refer to the keys and the values, respectively.
 
-Assume a `my.contexts` maps magic `String` values to an integer, as shown in the following example:
+Assume a `my.contexts` maps magic javadoc:java.lang.String[] values to an integer, as shown in the following example:
 
 include-code::MyProperties[]
 
@@ -42,7 +42,7 @@ In order to offer additional content assistance for the keys, you could add the
 ]}
 ----
 
-TIP: We recommend that you use an `Enum` for those two values instead.
+TIP: We recommend that you use an javadoc:java.lang.Enum[] for those two values instead.
 If your IDE supports it, this is by far the most effective approach to auto-completion.
 
 
@@ -139,7 +139,7 @@ This provider supports the following parameters:
 | Parameter | Type | Default value | Description
 
 | `target`
-| `String` (`Class`)
+| javadoc:java.lang.String[] (`Class`)
 | _none_
 | The fully qualified name of the class that should be assignable to the chosen value.
   Typically used to filter out-non candidate classes.
@@ -152,7 +152,7 @@ This provider supports the following parameters:
 |===
 
 
-The following metadata snippet corresponds to the standard `server.servlet.jsp.class-name` property that defines the class name to use must be an `HttpServlet`:
+The following metadata snippet corresponds to the standard `server.servlet.jsp.class-name` property that defines the class name to use must be an javadoc:jakarta.servlet.http.HttpServlet[]:
 
 [source,json]
 ----
@@ -177,7 +177,7 @@ The following metadata snippet corresponds to the standard `server.servlet.jsp.c
 === Handle As
 
 The **handle-as** provider lets you substitute the type of the property to a more high-level type.
-This typically happens when the property has a `java.lang.String` type, because you do not want your configuration classes to rely on classes that may not be on the classpath.
+This typically happens when the property has a javadoc:java.lang.String[] type, because you do not want your configuration classes to rely on classes that may not be on the classpath.
 This provider supports the following parameters:
 
 [cols="1,1,2,4"]
@@ -185,7 +185,7 @@ This provider supports the following parameters:
 | Parameter | Type | Default value | Description
 
 | **`target`**
-| `String` (`Class`)
+| javadoc:java.lang.String[] (`Class`)
 | _none_
 | The fully qualified name of the type to consider for the property.
   This parameter is mandatory.
@@ -193,17 +193,17 @@ This provider supports the following parameters:
 
 The following types can be used:
 
-* Any `java.lang.Enum`: Lists the possible values for the property.
-  (We recommend defining the property with the `Enum` type, as no further hint should be required for the IDE to auto-complete the values)
-* `java.nio.charset.Charset`: Supports auto-completion of charset/encoding values (such as `UTF-8`)
-* `java.util.Locale`: auto-completion of locales (such as `en_US`)
-* `org.springframework.util.MimeType`: Supports auto-completion of content type values (such as `text/plain`)
-* `org.springframework.core.io.Resource`: Supports auto-completion of Spring’s Resource abstraction to refer to a file on the filesystem or on the classpath (such as `classpath:/sample.properties`)
+* Any javadoc:java.lang.Enum[]: Lists the possible values for the property.
+  (We recommend defining the property with the javadoc:java.lang.Enum[] type, as no further hint should be required for the IDE to auto-complete the values)
+* javadoc:java.nio.charset.Charset[]: Supports auto-completion of charset/encoding values (such as `UTF-8`)
+* javadoc:java.util.Locale[]: auto-completion of locales (such as `en_US`)
+* javadoc:org.springframework.util.MimeType[]: Supports auto-completion of content type values (such as `text/plain`)
+* javadoc:org.springframework.core.io.Resource[]: Supports auto-completion of Spring’s Resource abstraction to refer to a file on the filesystem or on the classpath (such as `classpath:/sample.properties`)
 
-TIP: If multiple values can be provided, use a `java.util.Collection` or _Array_ type to teach the IDE about it.
+TIP: If multiple values can be provided, use a javadoc:java.util.Collection[] or _Array_ type to teach the IDE about it.
 
 The following metadata snippet corresponds to the standard `spring.liquibase.change-log` property that defines the path to the changelog to use.
-It is actually used internally as a `org.springframework.core.io.Resource` but cannot be exposed as such, because we need to keep the original String value to pass it to the Liquibase API.
+It is actually used internally as a javadoc:org.springframework.core.io.Resource[] but cannot be exposed as such, because we need to keep the original String value to pass it to the Liquibase API.
 
 [source,json]
 ----
@@ -323,13 +323,13 @@ This provider supports the following parameters:
 | Parameter | Type | Default value | Description
 
 | `target`
-| `String` (`Class`)
+| javadoc:java.lang.String[] (`Class`)
 | _none_
 | The fully qualified name of the bean class that should be assignable to the candidate.
   Typically used to filter out non-candidate beans.
 |===
 
-The following metadata snippet corresponds to the standard `spring.jmx.server` property that defines the name of the `MBeanServer` bean to use:
+The following metadata snippet corresponds to the standard `spring.jmx.server` property that defines the name of the javadoc:javax.management.MBeanServer[] bean to use:
 
 [source,json]
 ----
@@ -349,7 +349,7 @@ The following metadata snippet corresponds to the standard `spring.jmx.server` p
 ----
 
 NOTE: The binder is not aware of the metadata.
-If you provide that hint, you still need to transform the bean name into an actual Bean reference using by the `ApplicationContext`.
+If you provide that hint, you still need to transform the bean name into an actual Bean reference using by the javadoc:org.springframework.context.ApplicationContext[].
 
 
 

spring-boot-project/spring-boot-docs/src/docs/antora/modules/specification/pages/executable-jar/jarfile-class.adoc

@@ -1,9 +1,9 @@
 [[appendix.executable-jar.jarfile-class]]
 = Spring Boot's "`NestedJarFile`" Class
 
-The core class used to support loading nested jars is `org.springframework.boot.loader.jar.NestedJarFile`.
+The core class used to support loading nested jars is javadoc:org.springframework.boot.loader.jar.NestedJarFile[].
 It lets you load jar content from nested child jar data.
-When first loaded, the location of each `JarEntry` is mapped to a physical file offset of the outer jar, as shown in the following example:
+When first loaded, the location of each javadoc:java.util.jar.JarEntry[] is mapped to a physical file offset of the outer jar, as shown in the following example:
 
 [source]
 ----
@@ -30,7 +30,7 @@ We do not need to unpack the archive, and we do not need to read all entry data
 == Compatibility With the Standard Java "`JarFile`"
 
 Spring Boot Loader strives to remain compatible with existing code and libraries.
-`org.springframework.boot.loader.jar.NestedJarFile` extends from `java.util.jar.JarFile` and should work as a drop-in replacement.
+javadoc:org.springframework.boot.loader.jar.NestedJarFile[] extends from javadoc:java.util.jar.JarFile[] and should work as a drop-in replacement.
 
-Nested JAR URLs of the form `jar:nested:/path/myjar.jar/!BOOT-INF/lib/mylib.jar!/B.class` are supported and open a connection compatible with `java.net.JarURLConnection`.
-These can be used with Java's `URLClassLoader`.
+Nested JAR URLs of the form `jar:nested:/path/myjar.jar/!BOOT-INF/lib/mylib.jar!/B.class` are supported and open a connection compatible with javadoc:java.net.JarURLConnection[].
+These can be used with Java's javadoc:java.net.URLClassLoader[].

spring-boot-project/spring-boot-docs/src/docs/antora/modules/specification/pages/executable-jar/launching.adoc

@@ -1,16 +1,16 @@
 [[appendix.executable-jar.launching]]
 = Launching Executable Jars
 
-The `org.springframework.boot.loader.launch.Launcher` class is a special bootstrap class that is used as an executable jar's main entry point.
-It is the actual `Main-Class` in your jar file, and it is used to setup an appropriate `ClassLoader` and ultimately call your `main()` method.
+The javadoc:org.springframework.boot.loader.launch.Launcher[] class is a special bootstrap class that is used as an executable jar's main entry point.
+It is the actual `Main-Class` in your jar file, and it is used to setup an appropriate javadoc:java.lang.ClassLoader[] and ultimately call your `main()` method.
 
-There are three launcher subclasses (`JarLauncher`, `WarLauncher`, and `PropertiesLauncher`).
+There are three launcher subclasses (`JarLauncher`, javadoc:org.springframework.boot.loader.launch.WarLauncher[], and javadoc:org.springframework.boot.loader.launch.PropertiesLauncher[]).
 Their purpose is to load resources (`.class` files and so on) from nested jar files or war files in directories (as opposed to those explicitly on the classpath).
-In the case of `JarLauncher` and `WarLauncher`, the nested paths are fixed.
-`JarLauncher` looks in `BOOT-INF/lib/`, and `WarLauncher` looks in `WEB-INF/lib/` and `WEB-INF/lib-provided/`.
+In the case of javadoc:org.springframework.boot.loader.launch.JarLauncher[] and javadoc:org.springframework.boot.loader.launch.WarLauncher[], the nested paths are fixed.
+javadoc:org.springframework.boot.loader.launch.JarLauncher[] looks in `BOOT-INF/lib/`, and javadoc:org.springframework.boot.loader.launch.WarLauncher[] looks in `WEB-INF/lib/` and `WEB-INF/lib-provided/`.
 You can add extra jars in those locations if you want more.
 
-The `PropertiesLauncher` looks in `BOOT-INF/lib/` in your application archive by default.
+The javadoc:org.springframework.boot.loader.launch.PropertiesLauncher[] looks in `BOOT-INF/lib/` in your application archive by default.
 You can add additional locations by setting an environment variable called `LOADER_PATH` or `loader.path` in `loader.properties` (which is a comma-separated list of directories, archives, or directories within archives).
 
 
@@ -18,7 +18,7 @@ You can add additional locations by setting an environment variable called `LOAD
 [[appendix.executable-jar.launching.manifest]]
 == Launcher Manifest
 
-You need to specify an appropriate `org.springframework.boot.loader.launch.Launcher` as the `Main-Class` attribute of `META-INF/MANIFEST.MF`.
+You need to specify an appropriate javadoc:org.springframework.boot.loader.launch.Launcher[] as the `Main-Class` attribute of `META-INF/MANIFEST.MF`.
 The actual class that you want to launch (that is, the class that contains a `main` method) should be specified in the `Start-Class` attribute.
 
 The following example shows a typical `MANIFEST.MF` for an executable jar file:

spring-boot-project/spring-boot-docs/src/docs/antora/modules/specification/pages/executable-jar/property-launcher.adoc

@@ -1,7 +1,7 @@
 [[appendix.executable-jar.property-launcher]]
 = PropertiesLauncher Features
 
-`PropertiesLauncher` has a few special features that can be enabled with external properties (System properties, environment variables, manifest entries, or `loader.properties`).
+javadoc:org.springframework.boot.loader.launch.PropertiesLauncher[] has a few special features that can be enabled with external properties (System properties, environment variables, manifest entries, or `loader.properties`).
 The following table describes these properties:
 
 |===
@@ -68,7 +68,7 @@ When specified as environment variables or manifest entries, the following names
 TIP: Build plugins automatically move the `Main-Class` attribute to `Start-Class` when the uber jar is built.
 If you use that, specify the name of the class to launch by using the `Main-Class` attribute and leaving out `Start-Class`.
 
-The following rules apply to working with `PropertiesLauncher`:
+The following rules apply to working with javadoc:org.springframework.boot.loader.launch.PropertiesLauncher[]:
 
 * `loader.properties` is searched for in `loader.home`, then in the root of the classpath, and then in `classpath:/BOOT-INF/classes`.
   The first location where a file with that name exists is used.
@@ -76,7 +76,7 @@ The following rules apply to working with `PropertiesLauncher`:
 * `loader.path` can contain directories (which are scanned recursively for jar and zip files), archive paths, a directory within an archive that is scanned for jar files (for example, `dependencies.jar!/lib`), or wildcard patterns (for the default JVM behavior).
   Archive paths can be relative to `loader.home` or anywhere in the file system with a `jar:file:` prefix.
 * `loader.path` (if empty) defaults to `BOOT-INF/lib` (meaning a local directory or a nested one if running from an archive).
-  Because of this, `PropertiesLauncher` behaves the same as `JarLauncher` when no additional configuration is provided.
-* `loader.path` can not be used to configure the location of `loader.properties` (the classpath used to search for the latter is the JVM classpath when `PropertiesLauncher` is launched).
+  Because of this, javadoc:org.springframework.boot.loader.launch.PropertiesLauncher[] behaves the same as javadoc:org.springframework.boot.loader.launch.JarLauncher[] when no additional configuration is provided.
+* `loader.path` can not be used to configure the location of `loader.properties` (the classpath used to search for the latter is the JVM classpath when javadoc:org.springframework.boot.loader.launch.PropertiesLauncher[] is launched).
 * Placeholder replacement is done from System and environment variables plus the properties file itself on all values before use.
 * The search order for properties (where it makes sense to look in more than one place) is environment variables, system properties, `loader.properties`, the exploded archive manifest, and the archive manifest.

spring-boot-project/spring-boot-docs/src/docs/antora/modules/specification/pages/executable-jar/restrictions.adoc

@@ -7,7 +7,7 @@ You need to consider the following restrictions when working with a Spring Boot
 
 [[appendix.executable-jar-zip-entry-compression]]
 * Zip entry compression:
-The `ZipEntry` for a nested jar must be saved by using the javadoc:java.util.zip.ZipEntry#STORED[] method.
+The javadoc:java.util.zip.ZipEntry[] for a nested jar must be saved by using the javadoc:java.util.zip.ZipEntry#STORED[] method.
 This is required so that we can seek directly to individual content within the nested jar.
 The content of the nested jar file itself can still be compressed, as can any other entry in the outer jar.