Added an api method to unload plugins#649
Conversation
|
This functionality isn’t something that should be supported in any scenario. Un-or-reloading of plugins at runtime is never completely clean and leads to more issues than it solves. I hope that the paper team shares my notion to reject this |
|
There are many, many plugins that do not tolerate being cleaned up in this fashion. This was something we learned from Bukkit/Spigot and it wasn't a good idea then, and it isn't a good idea now. Major plugins like ViaVersion already provide no guarantee of support if unloaded at run time. We should not do this. |
|
well i would say its developers responsibility unload correct plugins. like not unloading the plugin that serves dependency for other plugins. other option is to remove classloader release. so whats the better way for this? |
|
The JVM was not designed to deal with this and I see little reason for trying to support this mess given that there are already plugins out there which allow people to shoot themselves in the foot for this |
|
true, but just calling onDisable and unregister plugins commands,listeners,tasks and removing it from loaded plugins would be less mess i suppose. please correct me if i am wrong. |
so finally a api method to unload plugins fully at runtime. requested by an user on waterfall discord