When a ServerEntity instance is first constructed, it uses a pre-Java 9 empty collection,
but passengers use Guava ImmutableList. When comparing the two collections via Object#equals
we miss out on an opportunity to reduce the check to little more than a reference equality
check (which is very fast).
On servers with plugins that constantly churn through scoreboards, there is a risk of degraded GC performance due to the number of scoreboards held on by weak references. Most plugins don't even need the (vanilla) functionality that requires all plugin scoreboards to be tracked by the server. Instead, only track scoreboards when an objective is added with a non-dummy criteria.
This is a breaking change, however the change is a much more sensible default. In case this breaks your workflow you can always force all scoreboards to be tracked with settings.track-plugin-scoreboards in paper.yml.
While Velocity supports BungeeCord-style IP forwarding, it is not secure. Users
have a lot of problems setting up firewalls or setting up plugins like IPWhitelist.
Further, the BungeeCord IP forwarding protocol still retains essentially its original
form, when there is brand new support for custom login plugin messages in 1.13.
Velocity's modern IP forwarding uses an HMAC-SHA256 code to ensure authenticity
of messages, is packed into a binary format that is smaller than BungeeCord's
forwarding, and is integrated into the Minecraft login process by using the 1.13
login plugin message packet.
Removes a layer of indirection for EnumDirection.getAdjacent(X|Y|Z)(), which is in the
critical section for much of the server, including the lighting engine.
The history of how paths work in Win32 is a sad story and shall not be documented here.
Needless to say, Windows hates the temporary file name for jansi's native code since it
includes the version. For git builds, it includes quotes around the actual version. But
alas, the issue apparently doesn't occur if you build on Windows since it removes the
quotes from the git commandline that is ultimately used to build the version string,
because of more Win32 sadness and shame.
Go look at Raymond Chen's blog, The Old New Thing. It's full of Windows oddities and
it will make you want to weep because almost 90% of the world uses this legacy OS from
the 1980s.
On servers with plugins that constantly churn through scoreboards, there is a risk of
degraded GC performance due to the number of scoreboards held on by weak references.
Most plugins don't even need the (vanilla) functionality that requires all plugin
scoreboards to be tracked by the server. Instead, only track scoreboards when an
objective is added with a non-dummy criteria.
This is a breaking change, however the change is a much more sensible default. In case
this breaks your workflow you can always force all scoreboards to be tracked with
settings.track-plugin-scoreboards in paper.yml.