The plugin class

The entry-point for any plugin is the own plugin class.
Typically, the plugin class does not contain actual work logic but initializes services, listeners and other parts involved in the work of the plugin.
The plugin class can also handle/help interaction between the parts of the plugin.

1. Annotation / Plugin discovery

In order for a plugin class to be discovered, it must be annotated with the @JeakBotPlugin annotation.
The annotation also requires the developer to set a (preferably) unique plugin ID for that class.

2. Restrictions

Constructors

Plugin classes will be instantiated by the PluginManager during the loading process.

Therefore, all plugin classes can only have a no-parameter constructor or inherit their constructor from their parent class. Other constructor signatures are not supported nor used.
Constructors are also forbidden to start loading processes as will be discussed in the Phases documentation.

State

By definition, instances of the plugin class shall not share any state information to allow multiple instances of the plugin to operate in the same JVM without interfering with each other.
If you don't see another way, feel free to talk to the community to get quirks out of the data flow.

Visibility

For obvious reasons, the class must be publicly visible in order to be usable to the bot.

2. Example

Aside from the annotation for discovery and the restrictions above, there are no additional mandatory requirements to a class in order to be considered a plugin class.
This for example is a perfectly valid plugin class:

package de.fearnixx.jeak;

import de.fearnixx.jeak.reflect.JeakBotPlugin;

@JeakBotPlugin(id = "sometestplugin")
public class TestPlugin {
  
}

Quick summary - The above class...

... is publicly visible
... is annotated with @JeakBotPlugin
... has an ID
... inherits a no-parameter constructor (from Object)

Therefore, it can be used by the framework.