Shane Freeder

Cleaning this up has generally been on the low priority todo list for a while, especially for network level stuff where the trace provides no real context

I feel that this just furthers the complexity. Do we consider adding a new method with a maybe more explicit name so that we can pair it with a has/is...

blindly cloning the original item negates a good chunk of the perf improvements here, would defo need that to at least be in the fire event, but, afaik, the patch...

Would need a jstack in order to see what the entire JVM is doing, given that it looks like something has potentially locked itself up

Maybe make this configurable instead of just removing it? I feel that there is a bit of a fun one here where mojang doesn't really care too much about server...

I thought that the maths might end up matching differently or something, kinda dubious on just removing something like this mid cycle

True, I guess; I guess it would maybe make sense to try to point to people about those recommendations somewhere, the entire reason we patched this was because it was...

I'm just thinking that if we're going to remove something that was intentionally added because we know it was being abused on servers, we should probably try to do something...

a bunch of things probably should have had config options when we added them, we have also generally been considering these builds "probably stable but we can't really go back...

For something that was actively being exploited, and there being a test jar for it, I was just thinking to slap an announcement "hey, we're removing our fix for this,...