Solved getConfig() weird behavior

Base code:

Code:

public static int highestLevel;
public static boolean glowLore;
 
@Override
public void onEnable() {
    if(!(new File(getDataFolder(), "config.yml").exists())) {
        saveDefaultConfig();
    }
     
    System.out.println(getConfig().saveToString());
     
    if(getConfig().get("highestLevelLimit") == null) {
        System.out.println("1");
        getConfig().set("highestLevelLimit", 5);
        saveConfig();
    }
     
    if(getConfig().get("glowInLore") == null) {
        System.out.println("2");
        getConfig().set("glowInLore", true);
        saveConfig();
    }
     
    System.out.println(getConfig().saveToString());
}

Config.yml that saves when JavaPlugin#saveDefaultConfig() is called:

Code:

# Default Configuration File
anvil: false
highestLevelLimit: 5
glowInLore: true

When I remove the last two lines manually and then save, and reload, it refuses to add them back despite the checks in the onEnable. Neither 1 or 2 prints out, and both the println statements are the same.

 

Instead of null checking, use the ".contains" method. This may fix your problem.

 

No fix with this line

Code:

if(!getConfig().contains("highestLevelLimit"))

New code:

Show Spoiler Hide Spoiler

Code:

public static int highestLevel;
public static boolean glowLore;

@Override
public void onEnable() {
    if(!(new File(getDataFolder(), "config.yml").exists())) {
        saveDefaultConfig();
    }
  
    System.out.println(getConfig().saveToString());
  
    if(!getConfig().contains("highestLevelLimit")) {
        System.out.println("1");
        getConfig().set("highestLevelLimit", 5);
        saveConfig();
    }
  
    if(!getConfig().contains("glowInLore")) {
        System.out.println("2");
        getConfig().set("glowInLore", true);
        saveConfig();
    }
  
    System.out.println(getConfig().saveToString());
}

@Override
public void onDisable() {
  
}

 

@Drkmaster83
Are you sure the config does not contain "glowInLore"? Are you sure you are shutting down the server before making changes to the config (Are you sure the server is offline before removing the lines)?

 

If the getConfig() method returns a FileConfiguration (which gets refreshed in RAM with the file again) and is working properly, I shouldn't need to reboot the server and start another VM for it to update, all it should take is a reloadConfig() or a reload of the server.

 

Solved it myself!
Did some research on the JavaDocs and the functionality, and I figured out that the hierarchy is like so:
Plugin's Data Folder < Jar File < Code (if provided).
If an entry doesn't exist in the data folder, it defaults to the one in the Jar file. If the Jar file one doesn't have an entry, it returns null UNLESS you add a default to the configuration object (getConfig().addDefault("highestLevelLimit", 5)), which will persist until reloadConfig() is called (haven't tested to see if the default will stick when you saveConfig()).

In my case, my plugin's jar file had a config.yml with those values, so the getConfig().get() call was not returning null since it got it from the jar file. However, if I didn't have a default set in the code and the value didn't exist in the plugin's jar file, it would have returned null.

Same case with contains; it only returns null if it can't default to anything. However, it is interesting to note that getConfig().getKeys(false).contains() works as intended.

Finally, just keep in mind that this is purely for the case of the getConfig() method. This case was especially tricky since there was no path, but it was the base of the config. If I had put Path to get to these, I could have used getConfigurationSection() which would somehow have curved around this problem.