Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
fdef9473 Correct Material#isFuel for new experimental materials
42811598 SPIGOT-7293: Add Biome#CHERRY_GROVE
CraftBukkit Changes:
968d28df0 Fix availability of experimental datapack features in unit tests
Upstream has released updates that appear to apply and compile correctly.
This update has not been tested by PaperMC and as with ANY update, please do your own testing
Bukkit Changes:
6b3c598b PR-814: Add a method to send multiple equipment changes
181a984b Update Maven shade version to align with CraftBukkit
a5a36e32 Revert "Update Maven shade version to align with CraftBukkit"
7a8f4a42 Update Maven shade version to align with CraftBukkit
58327201 Add support for Java 20
CraftBukkit Changes:
b56426c7a PR-1142: Calculate explosion damage separately for each affected EntityComplexPart
fbe3410af PR-1140: Add a method to send multiple equipment changes
8434e3633 Add support for Java 20
c998a1d23 Increase outdated build delay
4a929b5d6 SPIGOT-7267: Fix EntityType#getTranslationKey() and add unit test
086d8dc8a SPIGOT-7268: CraftMetaPotion reads ShowParticles and ShowIcon properties incorrectly
8ba5e399e SPIGOT-7262: Improve visibility API
Spigot Changes:
a2190e30 Rebuild patches
A recent patch moved the internal unit tests to mokito, allowing
deep mocking to easily setup a mocked server instance.
While this change is useful, the server's Server#getItemFactory methods
is one of the hottest paths during unit testing, being called numerous
times by material tests.
As mokito mocks keep track of each invocation to allow for verifications
of invocations down the line, the server mock allocates a huge amount of
memory to keep track of all invocations, ultimately leading to an OOM
exception.
The previous solution solved this by increasing the tests memory to 2 GB,
however as of right now simply configuring the server mock as "stubOnly",
properly prevents the overflow of invocation records as none of the unit
test code relies on invocation verification.
