Move API notes to more obvious location

By: md_5 <git@md-5.net>
This commit is contained in:
Bukkit/Spigot 2020-06-01 19:23:49 +10:00
parent 7504d25db2
commit 036d0b41dd
2 changed files with 19 additions and 20 deletions

View File

@ -1,23 +1,4 @@
/**
* The root package of the Bukkit API, contains generalized API classes.
*
* Note: While the Bukkit API makes every effort to ensure stability, this is
* not guaranteed, especially across major versions. In particular the following
* is a (incomplete) list of things that are <b>not</b> API.
* <ul>
* <li>Implementing interfaces. The Bukkit API is designed to only be
* implemented by server software. Unless a class/interface is obviously
* designed for extension (eg {@link org.bukkit.scheduler.BukkitRunnable}), or
* explicitly marked as such, it should not be implemented by plugins. Although
* this can sometimes work, it is not guaranteed to do so and resulting bugs
* will be disregarded.</li>
* <li>Constructing inbuilt events. Although backwards compatibility is
* attempted where possible, it is sometimes not possible to add new fields to
* events without breaking existing constructors. To ensure that the API
* continues to evolve, event constructors are therefore not plugin API.</li>
* <li>Implementation classes. Concrete implementation classes packaged with
* Bukkit (eg those beginning with Simple) are not API. You should access them
* via their interfaces instead.</li>
* </ul>
*/
package org.bukkit;

View File

@ -13,5 +13,23 @@
</p><p>
For handling events and triggered code, see the {@link org.bukkit.event
event package}.
</p>
</p><p>
Note: While the Bukkit API makes every effort to ensure stability, this is
not guaranteed, especially across major versions. In particular the
following is a (incomplete) list of things that are <b>not</b> API.
<ul>
<li>Implementing interfaces. The Bukkit API is designed to only be
implemented by server software. Unless a class/interface is obviously
designed for extension (eg {@link org.bukkit.scheduler.BukkitRunnable}), or
explicitly marked as such, it should not be implemented by plugins. Although
this can sometimes work, it is not guaranteed to do so and resulting bugs
will be disregarded.</li>
<li>Constructing inbuilt events. Although backwards compatibility is
attempted where possible, it is sometimes not possible to add new fields to
events without breaking existing constructors. To ensure that the API
continues to evolve, event constructors are therefore not plugin API.</li>
<li>Implementation classes. Concrete implementation classes packaged with
Bukkit (eg those beginning with Simple) are not API. You should access them
via their interfaces instead.</li>
</ul>
</body>