Bukkit
Public
Commits
md_5 authored 17f7097c13c
| 11 11 | For basic plugin development, see the {@link org.bukkit.plugin plugin |
| 12 12 | package}. It covers the basic requirements of a plugin jar. |
| 13 13 | </p><p> |
| 14 14 | For handling events and triggered code, see the {@link org.bukkit.event |
| 15 15 | event package}. |
| 16 16 | </p><p> |
| 17 17 | Note: While the Bukkit API makes every effort to ensure stability, this is |
| 18 18 | not guaranteed, especially across major versions. In particular the |
| 19 19 | following is a (incomplete) list of things that are <b>not</b> API. |
| 20 20 | <ul> |
| 21 - | <li>Implementing interfaces. The Bukkit API is designed to only be |
| 21 + | <li>Implementing interfaces or extending classes. The Bukkit API is designed to only be |
| 22 22 | implemented by server software. Unless a class/interface is obviously |
| 23 23 | designed for extension (eg {@link org.bukkit.scheduler.BukkitRunnable}), or |
| 24 - | explicitly marked as such, it should not be implemented by plugins. Although |
| 24 + | explicitly marked as such, it should not be implemented or extended by plugins. Although |
| 25 25 | this can sometimes work, it is not guaranteed to do so and resulting bugs |
| 26 26 | will be disregarded.</li> |
| 27 27 | <li>Constructing inbuilt events. Although backwards compatibility is |
| 28 28 | attempted where possible, it is sometimes not possible to add new fields to |
| 29 29 | events without breaking existing constructors. To ensure that the API |
| 30 30 | continues to evolve, event constructors are therefore not plugin API.</li> |
| 31 31 | <li>Implementation classes. Concrete implementation classes packaged with |
| 32 32 | Bukkit (eg those beginning with Simple) are not API. You should access them |
| 33 33 | via their interfaces instead.</li> |
| 34 34 | </ul> |
| 35 35 | </body> |