Update checkstyle

build.gradle

@@ -271,7 +271,7 @@ allprojects {
 
 	checkstyle {
 		configFile = rootProject.file("checkstyle.xml")
-		toolVersion = "10.12.1"
+		toolVersion = "10.20.2"
 	}
 
 	tasks.withType(AbstractArchiveTask).configureEach {

fabric-api-lookup-api-v1/src/main/java/net/fabricmc/fabric/api/lookup/v1/block/BlockApiLookup.java

@@ -40,7 +40,7 @@
  *
  * <p>Note: If you are going to query APIs a lot, consider using {@link BlockApiCache}, it may drastically improve performance.
  *
- * <p><h3>Usage Example</h3>
+ * <h3>Usage Example</h3>
  * Let us pretend we have the following interface that we would like to attach to some blocks depending on the direction.
  *
  * <pre>{@code
@@ -106,7 +106,7 @@
  *     // return something if available, or null
  * });}</pre>
  *
- * <p><h3>Improving performance</h3>
+ * <h3>Improving performance</h3>
  * When performing queries every tick, it is recommended to use {@link BlockApiCache BlockApiCache&lt;A, C&gt;}
  * instead of directly querying the {@code BlockApiLookup}.
  *
@@ -129,7 +129,7 @@
  *
  * // no need to destroy the cache, the garbage collector will take care of it}</pre>
  *
- * <p><h3>Generic context types</h3>
+ * <h3>Generic context types</h3>
  * Note that {@code FluidContainer} and {@code Direction} were completely arbitrary in this example.
  * We can define any {@code BlockApiLookup&lt;A, C&gt;}, where {@code A} is the type of the queried API, and {@code C} is the type of the additional context
  * (the direction parameter in the previous example).

fabric-api-lookup-api-v1/src/main/java/net/fabricmc/fabric/api/lookup/v1/custom/ApiLookupMap.java

@@ -29,7 +29,7 @@
  * A map meant to be used as the backing storage for custom {@code ApiLookup} instances,
  * to implement a custom equivalent of {@link net.fabricmc.fabric.api.lookup.v1.block.BlockApiLookup#get BlockApiLookup#get}.
  *
- * <p><h3>Usage Example</h3>
+ * <h3>Usage Example</h3>
  * We will be implementing the following simplified version of an API lookup interface for item stacks
  * to illustrate how to use {@link ApiLookupMap} and {@link ApiProviderMap}.
  * <pre>{@code

fabric-api-lookup-api-v1/src/main/java/net/fabricmc/fabric/api/lookup/v1/entity/EntityApiLookup.java

@@ -34,7 +34,7 @@
  * <p>When trying to {@link #find} an API for an entity, the provider registered for the entity type will be queried if it exists.
  * If it doesn't exist, or if it returns {@code null}, the fallback providers will be queried in order.
  *
- * <p><h3>Usage Example</h3>
+ * <h3>Usage Example</h3>
  * Let's pretend that we have the following interface that we want to attach to entities.
  * <pre>{@code
  * public interface Leveled {

fabric-api-lookup-api-v1/src/main/java/net/fabricmc/fabric/api/lookup/v1/item/ItemApiLookup.java

@@ -34,7 +34,7 @@
  * <p>When trying to {@link #find} an API for an item stack, the provider registered for the item of the stack will be queried if it exists.
  * If it doesn't exist, or if it returns {@code null}, the fallback providers will be queried in order.
  *
- * <p><h3>Usage Example</h3>
+ * <h3>Usage Example</h3>
  * Let us reuse {@code FluidContainer} from {@linkplain BlockApiLookup the BlockApiLookup example}.
  * We will query {@code FluidContainer} instances from the stack directly.
  * We need no context, so we will use {@code Void}.
@@ -82,7 +82,7 @@
  *     // return something if available, or null
  * });}</pre>
  *
- * <p><h3>Generic context types</h3>
+ * <h3>Generic context types</h3>
  * Note that {@code FluidContainer} and {@code Void} were completely arbitrary in this example.
  * We can define any {@code ItemApiLookup&lt;A, C&gt;}, where {@code A} is the type of the queried API, and {@code C} is the type of the additional context
  * (the void parameter in the previous example).

fabric-api-lookup-api-v1/src/main/java/net/fabricmc/fabric/api/lookup/v1/package-info.java

@@ -20,15 +20,14 @@
  * <p>This module allows API instances to be associated with game objects without specifying how the association is implemented.
  * This is useful when the same API could be implemented more than once or implemented in different ways.</p>
  *
- * <p><h2>Definitions and purpose</h2>
+ * <h2>Definitions and purpose</h2>
  * <ul>
  *     <li>What we call an <i>API</i> is any object that can be offered or queried, possibly by different mods, to be used in an agreed-upon manner.</li>
  *     <li>This module allows flexible retrieving of such APIs, represented by the generic type {@code A}, from blocks in the world or from item stacks.</li>
  *     <li>It also provides building blocks for defining custom ways of retrieving APIs from other game objects.</li>
  * </ul>
- * </p>
  *
- * <p><h2>Retrieving APIs from blocks in the world</h2>
+ * <h2>Retrieving APIs from blocks in the world</h2>
  * <ul>
  *     <li>A block query for an API is an operation that takes a world, a block position, and additional context of type {@code C}, and uses that
  *     to find an object of type {@code A}, or {@code null} if there was no such object.</li>
@@ -42,9 +41,8 @@
  *     For optimal performance, it is better to store them in a {@code public static final} field instead of querying them multiple times.</li>
  *     <li>See {@link net.fabricmc.fabric.api.lookup.v1.block.BlockApiLookup BlockApiLookup} for example code.</li>
  * </ul>
- * </p>
  *
- * <p><h2>Retrieving APIs from item stacks</h2>
+ * <h2>Retrieving APIs from item stacks</h2>
  * <ul>
  *     <li>Item API queries work similarly to block queries.</li>
  *     <li>An item query for an API is an operation that takes an item stack, and additional context of type {@code C}, and uses that
@@ -57,9 +55,8 @@
  *     and should be stored in a {@code public static final} field.</li>
  *     <li>See {@link net.fabricmc.fabric.api.lookup.v1.item.ItemApiLookup ItemApiLookup} for example code.</li>
  * </ul>
- * </p>
  *
- * <p><h2>Retrieving APIs from entities</h2>
+ * <h2>Retrieving APIs from entities</h2>
  * <ul>
  *     <li>A query for an entity API takes an entity and additional context of type {@code C},
  *     and uses that to find an object of type {@code A}, or  {@code null} if there's no such object.</li>
@@ -71,9 +68,8 @@
  *     and should be stored in a {@code public static final} field.</li>
  *     <li>See {@link net.fabricmc.fabric.api.lookup.v1.entity.EntityApiLookup EntityApiLookup} for example code.</li>
  * </ul>
- * </p>
  *
- * <p><h2>Retrieving APIs from custom game objects</h2>
+ * <h2>Retrieving APIs from custom game objects</h2>
  * <ul>
  *     <li>The subpackage {@code custom} provides helper classes to accelerate implementations of {@code ApiLookup}s for custom objects,
  * similar to the existing {@link net.fabricmc.fabric.api.lookup.v1.block.BlockApiLookup BlockApiLookup}, but with different query parameters.</li>
@@ -82,6 +78,5 @@
  *     <li>{@link net.fabricmc.fabric.api.lookup.v1.custom.ApiProviderMap ApiProviderMap} is a fast thread-safe copy-on-write map meant to be used as the backing storage for registered providers.</li>
  *     <li>See {@link net.fabricmc.fabric.api.lookup.v1.custom.ApiLookupMap ApiLookupMap} for example code.</li>
  * </ul>
- * </p>
  */
 package net.fabricmc.fabric.api.lookup.v1;

fabric-biome-api-v1/src/main/java/net/fabricmc/fabric/api/biome/v1/TheEndBiomes.java

@@ -31,10 +31,10 @@ private TheEndBiomes() {
 	}
 
 	/**
-	 * <p>Adds the biome as a main end island biome with the specified weight; note that this includes the main island
+	 * Adds the biome as a main end island biome with the specified weight; note that this includes the main island
 	 * and some of the land encircling the empty space. Note that adding a biome to this region could potentially mess
 	 * with the generation of the center island and cause it to generate incorrectly; this method only exists for
-	 * consistency.</p>
+	 * consistency.
 	 *
 	 * @param biome  the biome to be added
 	 * @param weight the weight of the entry. The weight in this method corresponds to its selection likelihood, with
@@ -46,8 +46,8 @@ public static void addMainIslandBiome(RegistryKey<Biome> biome, double weight) {
 	}
 
 	/**
-	 * <p>Adds the biome as an end highlands biome with the specified weight. End Highlands biomes make up the
-	 * center region of the large outer islands in The End.</p>
+	 * Adds the biome as an end highlands biome with the specified weight. End Highlands biomes make up the
+	 * center region of the large outer islands in The End.
 	 *
 	 * @param biome  the biome to be added
 	 * @param weight the weight of the entry. The weight in this method corresponds to its selection likelihood, with
@@ -59,8 +59,8 @@ public static void addHighlandsBiome(RegistryKey<Biome> biome, double weight) {
 	}
 
 	/**
-	 * <p>Adds a custom biome as a small end islands biome with the specified weight; small end island biomes
-	 * make up the smaller islands in between the larger islands of the end.</p>
+	 * Adds a custom biome as a small end islands biome with the specified weight; small end island biomes
+	 * make up the smaller islands in between the larger islands of the end.
 	 *
 	 * @param biome  the biome to be added
 	 * @param weight the weight of the entry. The weight in this method corresponds to its selection likelihood, with
@@ -72,9 +72,9 @@ public static void addSmallIslandsBiome(RegistryKey<Biome> biome, double weight)
 	}
 
 	/**
-	 * <p>Adds the biome as an end midlands of the parent end highlands biome. End Midlands make up the area on
+	 * Adds the biome as an end midlands of the parent end highlands biome. End Midlands make up the area on
 	 * the large outer islands between the highlands and the barrens and are similar to edge biomes in the
-	 * overworld. If you don't call this method, the vanilla biome will be used by default.</p>
+	 * overworld. If you don't call this method, the vanilla biome will be used by default.
 	 *
 	 * @param highlands The highlands biome to where the midlands biome is added
 	 * @param midlands  the biome to be added as a midlands biome
@@ -87,9 +87,9 @@ public static void addMidlandsBiome(RegistryKey<Biome> highlands, RegistryKey<Bi
 	}
 
 	/**
-	 * <p>Adds the biome as an end barrens of the parent end highlands biome. End Midlands make up the area on
+	 * Adds the biome as an end barrens of the parent end highlands biome. End Midlands make up the area on
 	 * the edge of the large outer islands and are similar to edge biomes in the overworld. If you don't call
-	 * this method, the vanilla biome will be used by default.</p>
+	 * this method, the vanilla biome will be used by default.
 	 *
 	 * @param highlands The highlands biome to where the barrens biome is added
 	 * @param barrens   the biome to be added as a barrens biome

fabric-convention-tags-v2/src/main/java/net/fabricmc/fabric/api/tag/convention/v2/ConventionalBiomeTags.java

@@ -48,8 +48,8 @@ private ConventionalBiomeTags() {
 	 * Biomes that spawn in the Overworld.
 	 * (This is for people who want to tag their biomes as Overworld without getting
 	 * side effects from {@link net.minecraft.registry.tag.BiomeTags#IS_OVERWORLD}.
-	 * <p></p>
-	 * NOTE: If you do not add to the vanilla Overworld tag, be sure to add to
+	 *
+	 * <p>NOTE: If you do not add to the vanilla Overworld tag, be sure to add to
 	 * {@link net.minecraft.registry.tag.BiomeTags#STRONGHOLD_HAS_STRUCTURE} so
 	 * some Strongholds do not go missing.)
 	 */

fabric-convention-tags-v2/src/main/java/net/fabricmc/fabric/api/tag/convention/v2/ConventionalBlockTags.java

@@ -121,8 +121,8 @@ private ConventionalBlockTags() {
 	/**
 	 * A storage block is generally a block that has a recipe to craft a bulk of 1 kind of resource to a block
 	 * and has a mirror recipe to reverse the crafting with no loss in resources.
-	 * <p></p>
-	 * Honey Block is special in that the reversing recipe is not a perfect mirror of the crafting recipe
+	 *
+	 * <p>Honey Block is special in that the reversing recipe is not a perfect mirror of the crafting recipe
 	 * and so, it is considered a special case and not given a storage block tag.
 	 */
 	public static final TagKey<Block> STORAGE_BLOCKS = register("storage_blocks");

fabric-convention-tags-v2/src/main/java/net/fabricmc/fabric/api/tag/convention/v2/ConventionalFluidTags.java

@@ -24,8 +24,8 @@
 /**
  * See {@link net.minecraft.registry.tag.FluidTags} for vanilla tags.
  * Note that addition to some vanilla tags implies having certain functionality.
- * <p></p>
- * Note, fluid tags should not be plural to match the vanilla standard.
+ *
+ * <p>Note, fluid tags should not be plural to match the vanilla standard.
  * This is the only tag category exempted from many-different-types plural rule.
  *
  * <p>(See {@link net.fabricmc.fabric.api.transfer.v1.fluid.FluidConstants} for the correct droplet rates for containers)

fabric-convention-tags-v2/src/main/java/net/fabricmc/fabric/api/tag/convention/v2/ConventionalItemTags.java

@@ -275,8 +275,8 @@ private ConventionalItemTags() {
 	 * Tag that holds all blocks and items that can be dyed a specific color.
 	 * (Does not include color blending items like leather armor.
 	 * Use {@link net.minecraft.registry.tag.ItemTags#DYEABLE} tag instead for color blending items)
-	 * <p></p>
-	 * Note: Use custom ingredients in recipes to do tag intersections and/or tag exclusions
+	 *
+	 * <p>Note: Use custom ingredients in recipes to do tag intersections and/or tag exclusions
 	 * to make more powerful recipes utilizing multiple tags such as dyed tags for an ingredient.
 	 * See {@link net.fabricmc.fabric.api.recipe.v1.ingredient.DefaultCustomIngredients}
 	 * children classes for various custom ingredients available that can also be used in data generation.
@@ -303,8 +303,8 @@ private ConventionalItemTags() {
 	/**
 	 * A storage block is generally a block that has a recipe to craft a bulk of 1 kind of resource to a block
 	 * and has a mirror recipe to reverse the crafting with no loss in resources.
-	 * <p></p>
-	 * Honey Block is special in that the reversing recipe is not a perfect mirror of the crafting recipe
+	 *
+	 * <p>Honey Block is special in that the reversing recipe is not a perfect mirror of the crafting recipe
 	 * and so, it is considered a special case and not given a storage block tag.
 	 */
 	public static final TagKey<Item> STORAGE_BLOCKS = register("storage_blocks");

fabric-recipe-api-v1/src/main/java/net/fabricmc/fabric/impl/recipe/ingredient/CustomIngredientSync.java

@@ -38,7 +38,7 @@
  * If a specific client doesn't support a custom ingredient, we send the matching stacks as a regular ingredient.
  * This is fine since all recipe computation happens server-side anyway.
  *
- * <p><ul>
+ * <ul>
  *     <li>Each client sends a packet with the set of custom ingredients it supports.</li>
  *     <li>We store that set inside the {@link EncoderHandler} using {@link EncoderHandlerMixin}.</li>
  *     <li>When serializing a custom ingredient, we get access to the current {@link EncoderHandler},

fabric-resource-loader-v0/src/main/java/net/fabricmc/fabric/api/resource/package-info.java

@@ -17,37 +17,37 @@
 /**
  * The Resource Loader, version 0.
  *
- * <p><h3>Quick note about vocabulary in Minecraft:</h3></p>
- * <p>Resource Pack refers to both client-sided resource pack and data pack.</p>
+ * <h3>Quick note about vocabulary in Minecraft:</h3>
+ * Resource Pack refers to both client-sided resource pack and data pack.
  *
- * <p><h3>Modded Resource Pack Handling</h3></p>
- * <p>There are two types of resource packs that mods can provide.</p>
+ * <h3>Modded Resource Pack Handling</h3>
+ * There are two types of resource packs that mods can provide.
  *
- * <p><h4>Bundled Resource Pack</h4></p>
- * <p>Mods can "bundle" resource packs with the mod by putting files inside the {@code assets} or {@code data}
+ * <h4>Bundled Resource Pack</h4>
+ * Mods can "bundle" resource packs with the mod by putting files inside the {@code assets} or {@code data}
  * sub-directories of the {@code resources} directory. They are always enabled, initially loaded after the vanilla pack,
  * and cannot be disabled. Individual mods' packs are hidden to users in the Resource Pack option screen or the {@code /datapack}
  * command. Instead, a placeholder pack, named "Fabric Mods", will be displayed. This pack, with the ID {@code fabric}, provides
- * no resource itself; it is merely a marker used internally.</p>
+ * no resource itself; it is merely a marker used internally.
  *
- * <p><h4>Built-in Mod Resource Pack</h4></p>
- * <p>The Resource Loader adds manually registered mod resource packs. Those resource packs are located inside the
+ * <h4>Built-in Mod Resource Pack</h4>
+ * The Resource Loader adds manually registered mod resource packs. Those resource packs are located inside the
  * {@code resources/resourcepacks/} directory. For example, a built-in data pack with the ID {@code example:test} should be placed
  * under {@code resources/resourcepacks/test/data/}. The packs are then registered with
  * {@link net.fabricmc.fabric.api.resource.ResourceManagerHelper#registerBuiltinResourcePack(net.minecraft.util.Identifier, net.fabricmc.loader.api.ModContainer, net.fabricmc.fabric.api.resource.ResourcePackActivationType)}.
- * Users can manually enable or disable the packs, unless it is specified to be always enabled.</p>
+ * Users can manually enable or disable the packs, unless it is specified to be always enabled.
  *
- * <p><h4>Programmer Art and High Contrast Support</h4></p>
- * <p>Bundled resource packs support Programmer Art and High Contrast vanilla resource packs. Simply place assets
+ * <h4>Programmer Art and High Contrast Support</h4>
+ * Bundled resource packs support Programmer Art and High Contrast vanilla resource packs. Simply place assets
  * under {@code resources/programmer_art/assets/} or {@code resources/high_contrast/assets/}, respectively.
  * Internally, these are treated as a separate internal pack, loaded just after the respective vanilla pack.
- * Toggling the vanilla packs automatically toggles the bundled ones as well; you cannot separately enable or disable them.</p>
+ * Toggling the vanilla packs automatically toggles the bundled ones as well; you cannot separately enable or disable them.
  *
- * <p><h4>Example</h4></p>
- * <p>Mod A ({@code mod_a} provides a bundled resource pack with both Programmer Art and High Contrast support.
+ * <h4>Example</h4>
+ * Mod A ({@code mod_a} provides a bundled resource pack with both Programmer Art and High Contrast support.
  * Mod B ({@code mod_b}) provides a bundled resource pack and one built-in resource pack, Extra ({@code mod_b:extra}).
  * When neither the Programmer Art nor High Contrast is enabled, the user sees "Vanilla", "Fabric Mods", and "Extra" in the
- * Resource Packs screen. Internally, between Fabric Mods and Extra packs, two hidden packs exist: {@code mod_a} and {@code mod_b}.</p>
+ * Resource Packs screen. Internally, between Fabric Mods and Extra packs, two hidden packs exist: {@code mod_a} and {@code mod_b}.
  *
  * <p>Suppose the user then enables both the Programmer Art and High Contrast, and the Resource Packs screen lists
  * "Vanilla", "Fabric", Programmer Art, "Extra", and High Contrast. Internally, there are 4 hidden packs:</p>
@@ -60,11 +60,11 @@
  *
  * <p>Note that while the current behavior is to sort bundled resource packs by mod ID in descending order (A to Z), this may change over time.</p>
  *
- * <p><h3>Resource Reload Listener</h3></p>
- * <p>The Resource Loader allows mods to register resource reload listeners through
+ * <h3>Resource Reload Listener</h3>
+ * The Resource Loader allows mods to register resource reload listeners through
  * {@link net.fabricmc.fabric.api.resource.ResourceManagerHelper#registerReloadListener(net.fabricmc.fabric.api.resource.IdentifiableResourceReloadListener)},
  * which are triggered when resources are reloaded.
- * A resource reload listener can depend on another and vanilla resource reload listener identifiers may be found in {@link net.fabricmc.fabric.api.resource.ResourceReloadListenerKeys}.</p>
+ * A resource reload listener can depend on another and vanilla resource reload listener identifiers may be found in {@link net.fabricmc.fabric.api.resource.ResourceReloadListenerKeys}.
  */
 
 package net.fabricmc.fabric.api.resource;