From b353b5ec04bb76dadc5278c9f888d7468035f7b8 Mon Sep 17 00:00:00 2001
From: Auxilor <william.favierparsons1@gmail.com>
Date: Mon, 13 Dec 2021 10:45:33 +0000
Subject: [PATCH] More javadoc

---
 .../main/java/com/willfp/eco/core/Eco.java    | 26 +++++++++++--------
 .../config/interfaces/LoadableConfig.java     |  2 +-
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/eco-api/src/main/java/com/willfp/eco/core/Eco.java b/eco-api/src/main/java/com/willfp/eco/core/Eco.java
index fc27678b..a638899a 100644
--- a/eco-api/src/main/java/com/willfp/eco/core/Eco.java
+++ b/eco-api/src/main/java/com/willfp/eco/core/Eco.java
@@ -5,10 +5,13 @@ import org.jetbrains.annotations.ApiStatus;
 import org.jetbrains.annotations.NotNull;
 
 /**
- * Base class to hold the handler.
+ * Holds the instance of the eco handler for bridging between the frontend
+ * and backend.
  *
+ * @see Eco#getHandler()
  * @see Handler
  */
+@ApiStatus.Internal
 public final class Eco {
     /**
      * Instance of eco handler.
@@ -18,6 +21,7 @@ public final class Eco {
 
     /**
      * Set the handler.
+     *
      * @param handler The handler.
      */
     @ApiStatus.Internal
@@ -28,18 +32,18 @@ public final class Eco {
     }
 
     /**
-     * Get the instance of the eco handler.
+     * Get the instance of the eco handler; the bridge between the api frontend
+     * and the implementation backend.
      * <p>
-     * The handler is, in essence, a way to interface between the eco-api
-     * frontend module, and the eco-backend implementations.
+     * <strong>Do not use the handler in your plugins!</strong> It can and will contain
+     * breaking changes between minor versions and even patches, and you will create
+     * compatibility issues by using the handler. All parts of the handler have been abstracted
+     * into logically named API components that you can use.
      * <p>
-     * There shouldn't really be any reason to ever use the handler
-     * in your own plugins, and you are likely to break things. All parts of
-     * the handler are abstracted into logically named parts of the API.
-     * <p>
-     * In versions of eco before 6.12.0, the handler was considered part of
-     * the eco API, however it has since been moved into an internal component
-     * that shouldn't be used in your plugins.
+     * Prior to version 6.12.0, the handler was considered as an API component, but it has
+     * since been moved into an internal component, and in 6.17.0, the first breaking change
+     * was introduced to {@link com.willfp.eco.core.config.wrapper.ConfigFactory}. This means
+     * that any usages of the handler can now cause problems in your plugins.
      *
      * @return The handler.
      */
diff --git a/eco-api/src/main/java/com/willfp/eco/core/config/interfaces/LoadableConfig.java b/eco-api/src/main/java/com/willfp/eco/core/config/interfaces/LoadableConfig.java
index bb2aad58..d2c59dd3 100644
--- a/eco-api/src/main/java/com/willfp/eco/core/config/interfaces/LoadableConfig.java
+++ b/eco-api/src/main/java/com/willfp/eco/core/config/interfaces/LoadableConfig.java
@@ -48,7 +48,7 @@ public interface LoadableConfig extends Config {
      * Get bukkit {@link YamlConfiguration}.
      * <p>
      * This method is not recommended unless absolutely required as it
-     * only returns true if {@link this#getType()} is {@link com.willfp.eco.core.config.ConfigType#YAML},
+     * only returns true if the type of config is {@link com.willfp.eco.core.config.ConfigType#YAML},
      * and if the handle is an {@link YamlConfiguration} specifically. This depends on the internals
      * and the implementation, and so may cause problems - it exists mostly for parity with
      * {@link JavaPlugin#getConfig()}.