Expose PluginClassLoader addURL

[xIGBClutchIx]

Is your feature request related to a problem?

Starting with Java 16 this will be an issue with some plugins. Notability a big plugin like LuckPerms uses this.

Describe the solution you'd like.

I was wondering if we go could get easy access to adding a URL to the plugin class loader. Currently, addURL for the PluginClassLoader protected as it is the default set by URLClassLoader.

Adding this to PluginClassLoader would fix said issues.

@Override
public void addURL(URL url) {
    super.addURL(url);
}

Describe alternatives you've considered.

An alternative we could use would be a Dependency API. I personally wrote my own but it is still quite hacky with the loading. Example of such which does not work with Java 16 at all: DependenciesGen

Agreements

• I have searched for and ensured there isn't already an open issue regarding this.
• I have ensured the feature I'm requesting isn't already in the latest supported Paper build.

Other

I personally went to Spigot about said request but seems this has been a request feature for around 2 years with no resolve at all.

[lynxplay]

I hope upstream can accept this.
md_5 wasn't too disturbed by it back when the issue was first created, I am hoping the upcoming java 16 bump helps upstream to move their legs a little.

https://hub.spigotmc.org/stash/projects/SPIGOT/repos/bukkit/pull-requests/612/overview

[xIGBClutchIx]

Hopefully, I was fine with reflection on my end as I use it mostly privately but the Java 16 news kind of made it a pain with everything being so locked down now.

[lynxplay]

You'll still have to use reflection even if that PR is pulled, the PluginClassLoader is package private.
But you will be able to without a warning or an exception due to module restrictions.

[xIGBClutchIx]

Yeah, that is completely fine by me as I know it is quite a controversial change giving easy access to something like that. Maybe one-day Spigot or Paper could have a Dependency loader API ;P

[Proximyst]

I'd be more inclined to add new protected API to JavaPlugin that adds it, really. There's no need in closing it off, but also not entirely sure new API would fit at all.

@lucko Do you have any thoughts, as you recently brought it up?

[MiniDigger]

Maybe we can create a nicer api, rather than exposing this low level method?

[lynxplay]

There is definitely a need for such API, tho I doubt it would find its way into upstream, concerning how conservative spigot tends to be with systems that do not directly mirror the server.

Implementing a fully fletched new API takes time and work until it can be published. Concerning how many different ways people love to parse, load and configure their own libraries before injecting them a fully fletched API might be a pretty hard change to get right.

Concerning that the PluginClassLoader class is package private, it is barely being exposed to the API.
The upstream PR. for now, only restores the ability to reflectively access the method.

[lucko]

Starting with Java 16 this will be an issue with some plugins. Notability a big plugin like LuckPerms uses this.

It's not, LuckPerms is using a different workaround now that doesn't require reflection, Unsafe or accessing addURL.

However, yes, this would still be a nice API to add. I'd suggest something similar to what Velocity has. The idea of adding a protected method to JavaPlugin for this makes the most sense to me.

[electronicboy]

We've been talking about a maven loader for a good while, just never been a huge enough priority for us; Also then sorta fell into a conversation about maybe replacing plugin.yml with our own thing so we can make these changes and allow plugins to optionally use that instead of plugin.yml, allowing for starting up differently between paper/spigot easily, and creates other concerns especially in regards to classloaders in bukkit

I'm conflicted around exposing stuff, but I know that people rely on it due to things like spigots file limitations, so, I could understand the desire for this, ideally from upstream so that we can have something that works across the board, but, if not 🤷

[Proximyst]

At the very least, I believe that regardless of us implementing a Maven loader, we should publicise the addURL method in the class (feel free to open PR), so we don't break reflective methods there. The class itself would remain inaccessible in that case, as that wouldn't be necessary to publicise.

[lynxplay]

Completely agree. As stated above, I opened a PR on upstream at https://hub.spigotmc.org/stash/projects/SPIGOT/repos/bukkit/pull-requests/612/overview