Don't use SystemClassLoader to load craftbukkit

[MrSteppy]

Here is a line from the current source code:

final Class<?> cls = Class.forName(mainClass, true, ClassLoader.getSystemClassLoader());

https://github.com/PaperMC/Paperclip/blob/2d4c7b3bbd322d8b7f3bbe2fe33ecf627251c828/java8/src/main/java/io/papermc/paperclip/Paperclip.java#L227

This code is called when loading the craftbukkit main method and uses the SystemClassLoader to load those classes. If a developer now wants to load paperclip, craftbukkit and all those classes with a custom ClassLoader this single line ruins that for him, since Java tries (reasonably) a lot, to make it impossible to change the SystemClassLoader.

I would suggest to change the part ClassLoader.getSystemClassLoader() to Perpclip.class.getClassLoader() so that custom class loaders can be used to load the bukkit and minecraft classes

[DenWav]

Using the system classloader is very intentional, as certain things in CraftBukkit may get unhappy if it's not loaded by the system classloader. At this point we do this purely out of maximum-compatibility with CraftBukkit - we don't want it to have any idea that it wasn't started directly with java -jar.

Paperclip is a low-level jar patching & bootstrapper system, I'm not sure I can see a reason for Paperclip to be called by anything else other than the system classloader.

Here's what I'll do: I'll first check if Paperclip is running in the system classloader. If it is, we use the current system to modify the system classloader and start CraftBukkit.

If Paperclip is not running in the system classloader, but it is running in a URLClassLoader, we can handle that case as well.

If neither of those cases are true, Paperclip will error and quit.

For more flexibility in this area you could just run Paperclip with -Dpaperclip.patchonly=true and run the output jar however you want instead.

[MrSteppy]

Well, that option certanly helps a lot, thankyou