Shane Freeder

making this mutable in any capacity does not look safe?

I have intents down the line to rewrite how data is handled in the server, wanna make player file I/O non-blocking any modifications to this data must all be done...

I've dropped that suggestion in a place where we often speak to mojang devs, will see if they have any comments on this as the general handling of this always...

The notion of defining an API version is pointless a) The entire system as it stands is practically just a boolean check for if it's defined or not, there is...

The big issue is "how do we do that" The entire reason that we don't wanna expose commands inside of the new system is that they'd be tied to bukkits...

reloading is not exactly a mechanism supported by mojang, as such, it's not something that can be nicely exposed outside of the limited contexts that vanilla allows. Reloading random plugins...

you can use the jetbrains runtime + hotswap agent to drastically improve the hotswapping capabilities

it's a mutability issue, best we could do is add methods that return the new profile, or store the resolved profile in a seperate field so that the methods themselves...

Not sure what you mean; The issue here is the hashcode, if you change the uuid/name on a profile, it would cause the hashcode to change of the wrapper object...

Well, yea, but that doesn't fix the expected behavior of the current class/methods? I'm honestly confused on what you're getting at here