Too long constructor

Discussion in 'Plugin Development' started by matejdro, Feb 20, 2011.

Thread Status:
Not open for further replies.
  1. Offline


    You must be kidding me.

    com - i guess i must have it.
    matejdro - to keep my plugins organized in one folder
    monsterhunt - name of the plugin folder
    MonsterHunt - name of the plugin main class.

    How can i shorten that even more?
  2. Offline


    This: MonsterHunt(PluginLoader, Server, PluginDescriptionFile, File, File,ClassLoader)

    Is the part that is the "stupidly long constructor."

    The default constructor now works. Remove your constructor entirely. Move anything it was doing to onEnable.
  3. Offline


    Oh, i have that in my constructor:

    Can i remove that then?
  4. Offline


    Yep, no need to copy anything elsewhere in that case, just delete (or comment out) the code you posted.
  5. Offline


    Ah it works now, thanks!
  6. Offline



    For anyone who comes across this thread and is wondering how to move stuff you were doing in your constructor, simply start by looking at the methods you inherit.

    Anything you were able to do in the constructor, you should be able to do in onEnable using this.___ or local function calls available from extending JavaPlugin.
  7. Offline


    So what exactly should the constructor look like? Please sticky a post showing exactly what needs to be done. Some of us are Java newbies just trying to do what we're being told and the first thing I heard about this was when one of my plugin users started nagging me (as Craftbukkit told him to). I still don't have a clue what to do :-|
  8. Offline


    Just comment out the "super" line from the constructor.

    And yes, bukkit team should make a sticky or at least write it to "oops i broke your plugins" thread.
  9. Offline


    Since the constructor has changed, I'd opt for a -preEnable method which get's called when first loading the plugin (Bukkit startup)...
    In the pre-enable method all the nessecary attribute are available (and not null).
  10. Offline


    It doesn't actually break plugins to use it, just throws warnings right now. That's probably why they haven't posted much on it.

    I admit I have not fully tested myself, but you should be able to comment out the entire constructor, not just the super line. You shouldn't need a constructor at all, the default constructor will take care of things.

    From my understanding, it shouldn't. Comment out the entire constructor. If you were doing anything there, move it to onEnable.

    What would this enable you to do that can't be done in onEnable?
  11. Offline


    I removed my constructor and my plugin broke =/ All it has in it issuper(pluginLoader, instance, desc, folder, plugin, cLoader);
  12. Offline


    Did you remove the entire constructor, not just the super line?

    Is your craftbukkit updated?

    This change breaks backwards compatibility. Plugins without the constructor can't be run on older CraftBukkit versions.

    You may want to make a pre-constructor-change and a post-constructor-change version available for a while.
  13. Offline


    If I do that I get an error that there is not constructor...
  14. Offline


  15. Offline


    create a default constructor if you need one
    public PluginName extends JavaPlugin {
        Pluginname() {
            ....code here ....
    not necessarily the best idea as if you only need to do something once (like allocating memory or initializing a variable) it should be done in the constructor
  16. Offline


    Maybe some things should be done in the constructor(like before), except in the 'new' constructor not all the variable of bukkit are available/initialized.

    getDescription(); returns a null when called in the contructor for example. So some things I cannot do in the constructor, but I can't do them in onEnable either, because I need to initialize a variable before other plugins get enabled.

    I would 'finish/complete' the loading in onEnable and I would code my plugin so that it can be called multiple times. Allowing Bukkit to enable or disable my plugin when needed.
  17. Offline


    This is more what I meant to say, although it's definitely not what I wrote:

    Anything you were doing with the constructor's parameters can (and it seems, should) be done in onEnable.

    Other local memory initialization, etc, may still be better done in a constructor if it is not reliant on inherited methods, and only needs to be done once, as the response 'could change' after a server /reload.

    The only risk then is: To what level is a plugin disabled when a server is restarted? Is memory released? If so, is it possible you're reclaiming the same memory and not seeing an error? (I don't know the answer, not saying it is. Saying I don't know, asking if you do...)

    E: Hmm... what do you need to initialize ahead of other plugins, Wrecker?
  18. Offline


    What does that error means?

    I don't get that error, but several people got it. I posted my CraftBukkit and plugin JAR so they are using identical to mine.
  19. Offline


    None of that told me:

    1. What CraftBukkit Version you are running.

    2. What Bukkit Version you compiled with.

    3. What you are trying to do in your constructor, and what you are trying to do in onEnable.
  20. Offline


    well, when the server is restarting the JVM releases all of the memory to the OS, its just better if you clear a list/map/whatever_storage instead of creating a new one IMO, also for data initialization you might want to set the data once and keep the information that changed if the plugin is disabled then re-enabled
  21. Offline



    Just an object which handles some settings which can be accessed by another plugin again. Sort of a group based settings system I've made. Which in turn can use either Permissions or a fallback permission system.

    Allows to create setting/config files based on groups. So admins can have another setting than a normal user in a certain plugin.
    --- merged: Feb 21, 2011 1:15 AM ---
    I agree. Except reload does not always mean all memory gets released. You have to be careful when you are using threads. A thread can keep running (including the resources it has) regardless of the state of the Bukkit server.
  22. Offline


    With Jenkins, I believe is the first build to implement the TSLPC (That Stupidly Long Plugin Constructor) check.

    Edit: Fixed it, I mistakenly thought it was build 42, but it is infact build 45.
  23. Offline


    Compiler error:
    "Implicit super constructor JavaPlugin() is undefined for default constructor. Must define an explicit constructor"

    Similar compiler error:
    "Implicit super constructor JavaPlugin() is undefined. Must explicitly invoke another constructor"

    I then spent a good hour chasing down where the correct version of bukkit API jar might be. Having tried three different download sources, I get this in each. And yet, somehow I feel like the idiot.
  24. Offline


    You need to update your Bukkit reference.
  25. Offline


    Sorry, I misspoke again. I was thinking about reloads in particular. Restarting the server would cause the constructor to be called. Reloading wouldn't.

    As Wrecker pointed out, not all of the methods you inherit are available when overriding the default constructor, which brings us back to a point where information needed is only accessible in onEnable. This leads me to believe that what the bukkit devs would like, and what would probably be best practice, is to only do things in the constructor which relate to memory your plugin creates and do not require information from JavaPlugin.

    From what I've seen, you should still be able to initialize your local data in the constructor based on the information stored in the config files. This data can then be manipulated inside of onEnable.

    It's hard to see your perspective without seeing what you're trying to do in your constructor and onEnable. Why do you need to access the plugin description yml in the constructor? Is there no other way you can provide the memory that other plugins need to see without reading that file?
  26. Offline


    It was an error in eclipse, like a compilation error. Nothing to do with craftbukkit.

    I thought I had, but I did again and it seems to have fixed it. Thanks!
  27. Offline


    well, you should be cleaning this up in the onDisable anyways if it should't be kept from one load to another, some things can be like configuration variables and those possibly shouldn't be reloaded since the disk io is not needed at all, though on another hand he said server restart and i thought that is what he meant instead of a plugin disable then enable
  28. Offline


    I'm not exactly needing the description, but I need the "File folder" and "File plugin" that was given to the constructor. I use those to look/acces files relative to the ones they point to.

    Yep cleaning up is a good thing. I just thought to point it out to the masses. Maybe it's helpful to some coder out there.
  29. Offline


    Warning, this suggestion is super-hacky, and will possibly lead to complaints from users who define their own plugin or plugin setting directories:

    First, check if your plugin has previously run and determined the directory 'typically' used. If it has, read the files from this folder.

    If your plugin hasn't run before, you might assume that in 95% of cases that the files will be in ./plugins/PluginName/ however, you can't assume this folder actually exists. (so you'll need to make sure first).

    If the folder exists, attempt to read the files you want from it.

    If the stored path or the ./plugins/PluginName/ path is not the path you read in onEnable, reload the info, and if necessary, reload the effected plugins.

    That said, Permissions already exists, as does what seems to be a successor to Permissions, and Bukkit will provide an official user/group interface. Are you sure that your system provides an advantage over what's currently available? Permissions does not force Admins to inherit from the default group, so having different commands or command actions for different user levels is certainly possible. The main thing that bugs me is the inability to set a deny permission, so I can give someone '*' and then subtract nodes.
  30. Offline



    I'll try to explain.

    Warning, this suggestion is super-hacky, and will possibly lead to complaints from users who define their own plugin or plugin setting directories:

    This is the main reason why I look at relative paths from the input given previously by the contructor! I know the directory can change where the plugin jars reside. And that's also true for where the datafolder resides. /plugins could be different, but that folder is not hardcoded in my plugin... You can actually retrieve that path from what is given to you through the constructor.... Doesn't actually seem that hacky to me.

    That said, Permissions already exists, as does what seems to be a successor to Permissions, and Bukkit will provide an official user/group interface. Are you sure that your system provides an advantage over what's currently available?
    I'm extending those plugins (Permissions) and not reinventing the proverbial wheel here. I actually support Permmisions plugin (V2.0 to be exact). I only implemented a fall back for the people who don't want to use permissions, but that's it. I just added features/uses on top of it. So yes, for me it's an advantage.

    The plugin actually contains more... A set of base classes which I extend from.

    If you have better options I would like to hear them though. Always good to hear what other people think and suggest.
Thread Status:
Not open for further replies.

Share This Page