The display name includes formatting such as item hover event, display name (in italics if renamed in anvil), and color based on rarity.
This is what vanilla uses for give command feedback, and when an item is shown in a death message.
CraftChatMessage.fromComponent fails to take into account the style of TranslatableComponent args, causing any styling on args to be completely ignored.
Fixing this is relatively simple, however would cause behavior to deviate from upstream. This commit will fix the coloring in messages logged through MinecraftServer.LOGGER by simply using Adventure's legacy text serializer, which properly serializes TranslatableComponents and their arguments. Note that this doesn't do anything about the underlying issue of CraftChatMessage.fromComponent improperly serializing TranslatableComponents.
Also use checkerframework annotations instead of jetbrains ones for Inventory#getContents as jetbrains ones do not allow properly annotating the nullability of an array and it's contents.
This fixes a confusing issue where doing 'merchant.setRecipes(merchant.getRecipes());' would clear the merchants recipes, as the implementation of getRecipes is guavas Lists.transform wrapped in Collections.unmodifiableList, and the implementation of setRecipes clears the backing list before adding the elements of the provided list to the backing list.
The javadoc for the getRecipes method says 'an immutable list of trades', so this patch makes the javadoc correct.
Instead of completely resetting a Villager's reputation for all players each time they are cured, we now only reset the relevant part of the reputation for only that player. This means the exploit is fixed and players cannot stack multiple cures until prices are down to 1, but doesn't have the same side effects that are commonly complained about with the current exploit fix.
Remove duplicate JavaDocs - At some point upstream decided to fix some of their JD errors/warnings, so now we have duplicate tags, bringing new warnings.
Also add missing `@param` for ItemStack.deserializeBytes
When new advancements are added via the UnsafeValues#loadAdvancement
API, it triggers a full datapack reload when this is not necessary. The
advancement is already loaded directly into the advancement registry,
and the point of saving the advancement to the Bukkit datapack seems to
be for persistence. By removing the call to reload datapacks when an
advancement is loaded, the client no longer completely freezes up when
adding a new advancement.
To ensure the client still receives the updated advancement data, we
manually reload the advancement data for all players, which
normally takes place as a part of the datapack reloading.
Jason Penilla