Solved There must be a better way.

I want to violently rip two listeners out of a single-class plugin and put them both in their own classes.

Unfortunately, I couldn't think of a better way to do this than changing a couple of methods from private to public (methods that manipulate arrays, which, honestly, should be in a static class as static methods anyway), adding public get() and set() methods for a private integer array, and passing a "reference" to the main plugin of the type the plugin is (not JavaPlugin plugin, MyPlugin plugin) where a lot of this is kept to the listener in its constructor.

public MyListener(MyPlugin p)... I feel dirty already.

First and foremost: Is there actually anything wrong with keeping three hundred lines of a simple plugin in one class? What if it became three thousand lines?

Second: Regardless of whether it is a good idea, or even necessary, is there a better way to access and methods from the plugin than "public MyListener(MyPlugin p)"?

 

There is nothing wrong with that, I have classes with thousands of lines. In general they just need to be related. Or from a OOP perspective they need to apply to the same object.

Have you considered package local?

 

I rather wanted them to be in a sub-package. It's conceivable that package local would be a fine visibility for the methods and even the array, if I were to change my mind about this.

Is it wrong to want the listener classes in, say, tld.domain.main.sub as opposed to tld.doman.main? Because I never properly learned about what should go in what package. In fact, when I was academically taught Java, the word "package" was heard maybe once. (Bleh, academic programming...) Perhaps I should explore resources about namespaces and such.

EDIT: Without having tested, I think we're done here. Thanks.