[SPIGOT-5352] Create public addURL method to PluginClassLoader Created: 04/Oct/19  Updated: 14/May/21

Status: Open
Project: Spigot
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Bjarne Koll Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: 1.14, class-loader, suggestion

Issue Links:
Duplicate
is duplicated by SPIGOT-6457 Expose PluginClassLoader addURL or De... Resolved
Relates
relates to SPIGOT-5345 Generic Java library support for plugins Resolved
Version: 1.14.4
Guidelines Read: Yes

 Description   

This suggestion is specific for the newer java versions, more specifically java 9 or above.

A lot of plugins on spigot that try to be as lightweight as possible, as well as work on a server network tend to load external libraries into their own class loader.

A few examples of those things that I found on spigot:
https://github.com/lucko/helper/blob/master/helper/src/main/java/me/lucko/helper/maven/LibraryLoader.java
https://www.spigotmc.org/threads/adding-external-library-to-server.386112/
https://www.spigotmc.org/threads/runtime-external-jar-loading-and-java-9.340156/

This approach worked perfectly fine for java 8, yet the version of the language is now a total of four major updates behind the latest release of java and the used call 

URLClassLoader#addURL(java.net.URL)

now ends up in an illegal access warning (https://stackoverflow.com/questions/50251798/what-is-an-illegal-reflective-access).

To fix this, spigots plugin class loader class (org.bukkit.plugin.java.PluginClassLoader) can implement a wrapper for the protected method of its parent class (the URLClassLoader).

Addition to the PluginClassLoader: 

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

This change has absolutely no affect on any of spigots behavior, as the method is not called at all during the normal class loader creation, but allows plugin developers to updated smoothly to java 9 or newer without having to sacrifice the ability to dynamically load libraries or other java classes into the plugins own class loader.

 Comments   
Comment by xIGBClutchIx [ 14/May/21 ]

This works beautifully just tested it. Put Kotlin as a library and loaded a plugin that was coded in Kotlin.

Comment by Bjarne Koll [ 14/May/21 ]

I agree that there is need for an API to load this, yet a) being capable of loading maven dependencies from maven central does very much not solve virtually every usecase of this method. Plugins loading custom modules are still done for.

This change is necessary as part of a potential API to solve this anyway. Adding this already really only eases developer experience for people running java 16 right now. If you feel like rushing an API addition for this to solve it instead, I guess I can't argue with this but I do not see the point of denying a change like this that a) will have to be done in the future and b) enables the respective group of plugin developers to deploy their plugins on java 16.

 

// EDIT
Looking at the library loader code further, what are your throughs about expanding on this concept to also enable loading local jar files through a similar process.
Could very much be a folder glob to point towards a module folder.

Comment by md_5 [ 14/May/21 ]

It has full dependency resolution, try it with the okhttp example

Comment by xIGBClutchIx [ 14/May/21 ]

Was not expecting a full API. Love to see it!

Does the loader only load the library list or will it pull down any child dependencies too?

Comment by md_5 [ 14/May/21 ]

Still against adding something that is used for reflection purposes only. If you're gonna make the change it should be done properly as API.
Bukkit also now allows loading any library from Maven central which should virtually eliminate the need for doing this: https://hub.spigotmc.org/stash/projects/SPIGOT/repos/bukkit/commits/146a7e4bd764990c56bb326643e92eb69f24d27e

Comment by xIGBClutchIx [ 13/May/21 ]

With Java 16 coming, this is definitely a bigger change that would help a lot now due to the class loader being locked down a lot more.

Comment by Bjarne Koll [ 01/Nov/19 ]

True, but reflective access to spigot (such as CommandMap etc) is something widly spread througout the community. Changes to the URLClassLoader were already reflective.

The proposed change is simply something no normal spigot user will notice but opens the possibility for certain developers that used to use the addURL method on the URLClassLoader to avoid warnings or errors in upcoming java version.

Comment by md_5 [ 01/Nov/19 ]

The thing is PluginClassLoader is not API, in fact the class itself is package private and can't be accessed without reflection....

Comment by Bjarne Koll [ 22/Oct/19 ]

Agreed, a lot of servers are still running on java 8, but we do slowly see a change away from oracle and java 8 to the newer openjdk versions and post jigsaw java :+1:

Comment by Evil Witchdoctor [ 22/Oct/19 ]

In addition to avoiding source-compliance issues like that example, many plugin authors choose to compile their plugins for Java 8 to avoid compatibility issues with server administrators who can't/won't update Java...

Still, I see the appeal

Generated at Fri Apr 11 16:22:09 UTC 2025 using Jira 10.3.3#10030003-sha1:d220e3fefc8dfc6d47f522d3b9a20c1455e12b7b.