Is this a bad idea?

Simply put, due to complicated interactions of various parts of a plugin I am writing, it is problematic to pass the plugin variable in the constructor of all of the non-main classes. Is storing the plugin variable like so

Code:

public static Plugin plugin;
 
@Override
public void onEnable(){
        plugin = this;
}

and accessing it in the form MainClass.plugin whenever I need it a really stupid idea for some reason I haven't picked up on? If it isn't a stupid idea, then why do people pass it in the constructor instead of storing it this way?

 

AFAIK if you store it as static, if it's not nulled on disable it won't be cleared by the garbage collector and there will end up being multiple instances of your plugin.

 

If that is the case, couldn't you just run

Code:

this.plugin = null;

in your onDisable()? I don't really understand how the Java garbage collector works, so sorry if this is a stupid question.

 

is it that hard to simply pass the plugin to any class that needs it?

 

At some point it is. E.g.:
Class a doesn't need the main instance, hence it doesn't hold any reference to it. In some cases it needs to create an instance of class b which needs a reference to the main class.
You would need to hold a reference to your main class in class a as well even when you might not need it. When you would have a static reference to your main class all this passing over the main instance wouldn't be needed since you can statically access it. There's nothing wrong about having a static reference to you main if you handle it correctly.

 

Have you tested this yourself? I never realy thought about it.

 

I use this methode as him inside my classes, I never found anny problems whit it

 

I always use constructors and avoid statics in plugin codes so I don't have to care about handling it correctly. Made my life a bit easier.

At all: Have a look at this thread for more information why statics are bad (if not handled correctly): http://forums.bukkit.org/threads/petition-to-remove-the-reload-command.43212/

 

Well, given how my plugin is structured, making it work with constructors seems like considerably more work than "handling it properly". What does "handling it properly" consist of? Is setting plugin to null onDisable all I need, or are there more steps involved?

 

That's about it really. Null it out in your onDisable(), and perhaps also check in your onEnable() that it's actually null before you assign it. Plugin classes (i.e. those that extend JavaPlugin) are all meant to be singletons, but there isn't anything other than self-regulation to enforce that. I'd also make the instance field private, and only get it via a public accessor method.

 

Alright, I'll go do that. Thanks so much to you all for the help!