Add support for private constructors in plugin main classes

[Wiicart]

Adds support for private constructors in plugin main classes, using Constructor#setAccessible(boolean), allowing for better encapsulation.

[Warriorrrr]

What is the benefit of allowing private constructors to be used?

[Strokkur424]

What is the benefit of allowing private constructors to be used?

The only benefit I can think of would be that it makes sure people, who use your plugin's API, which may come with internal classes exposed, cannot accidentally create an instance of your plugin's main class.

A potential solution to this is making the constructor package-private and creating the plugin instance with a plugin bootstrapper, but I can see how this might be non-ideal.

[mbax]

Doesn't creating a new javaplugin instance result in an exception already? I thought it did...

[Wiicart]

What Strokkur said is pretty much what I was thinking. I’ll admit I wasn’t aware of an Exception when making new JavaPlugin instances, but even so, I don’t think it would hurt to prevent it at compile time.

[Machine-Maker]

I think its probably fine to allow non-public constructors*.

[Owen1212055]

However, can you also please update ProviderUtil#loadClass? This way this applies to paper plugins too.

[NonSwag]

Isn't setAccessible unofficially deprecated? I think the replacement is called trySetAccessible

[Wiicart]

However, can you also please update ProviderUtil#loadClass? This way this applies to paper plugins too.

Done

Isn't setAccessible unofficially deprecated? I think the replacement is called trySetAccessible

I looked at trySetAccessible, the only difference is that instead of throwing an InaccessibleObjectException, it returns false, but it can still throw a SecurityException.