KOTLINプラグイン ジェネレーター
plugin.ymlを備えたGradleプロジェクトを用意し、ダウンロードの前にコンパイルまで行います。Kotlinのプラグインを生成するメリット
Bukkitで必要なnull安全性
Bukkitはオフラインのプレイヤー、存在しないワールド、ない設定キーなど、しょっちゅうnullを返します。Kotlinなら、そうしたケースを午前2時のサーバーコンソールではなく、コンパイル時に明示できます。
本物のGradleプロジェクト
Kotlin JVMプラグインとPaper/Spigotのリポジトリに対応したbuild.gradle.ktsと、標準的なソース構成を備えています。置き場所に困る単一ファイルではありません。
定型コードが大幅に減る
設定モデル用のデータクラス、PlayerやItemStackの拡張関数、入れ子のnullチェックの代わりのスコープ関数。同じロジックを、はっきり少ないコードで書けます。
FoliaとプロキシにもCodexeは対応
Paperのマルチスレッド版を使っている場合、Foliaにはメインスレッドが1つだけという前提がなく、リージョンを意識したスケジューリングが必要になります。最初からスケジューリングが正しくなるよう、プラグインジェネレーターでFoliaの対象を選んでください。ネットワークレベルの作業にはプロキシプラグインジェネレーターを使います。違いはプラグインのドキュメントで説明しています。
プロンプトの例
Kotlinプラグインジェネレーターのよくある質問
KotlinのプラグインはふつうのSpigotやPaperのサーバーで動きますか?
+
はい。KotlinはふつうのJVMバイトコードにコンパイルされるので、サーバーはプラグインがどの言語で書かれたかを知りませんし、気にもしません。Javaのプラグインとまったく同じように読み込まれます。
サーバー側で何かインストールする必要はありますか?
+
いいえ。Kotlinの標準ライブラリはビルド時にJARへシェーディングされるので、プラグインだけで完結します。そのため、同等のJavaプラグインよりJARは大きくなります。
MavenですかGradleですか?
+
Gradleです。Kotlinの対象では、JVM上のKotlinの標準ツールチェーンであるGradleのKotlinプラグインを使います。Javaの対象ではMavenを使います。
Kotlinを使うと、具体的に何が良いのですか?
+
主にnull安全性と、お決まりの記述の少なさです。Bukkit APIは、getPlayer、getWorld、設定の取得など、多くの場面でnullを返します。Kotlinの型システムなら、それをコンパイル時に処理するよう強制してくれるので、本番でNullPointerExceptionとして見つけることがありません。データクラス、拡張関数、スコープ関数によって、設定やリスナーのコードの定型部分も大きく減ります。
1つのプラグインにJavaとKotlinを混在できますか?
+
ジェネレーターが出力するのはKotlinのソースセットです。Gradleは混在したソースもコンパイルできるので、あとからJavaファイルを追加できますが、生成されるプロジェクトはKotlin中心です。
KotlinとJavaのどちらを選ぶべきですか?
+
チュートリアルや既存のコード片、他の人のコードとの互換性を最大限に重視するならJavaです。Bukkit関連の資料はほぼすべてJavaが前提だからです。Kotlinに慣れていて、より簡潔でnull安全なコードがほしいならKotlinを選んでください。APIの範囲はどちらも同じです。
ほかのCodexeジェネレーター
Prefer Java, or working somewhere else in the stack? Codexe also generates:
Codexeがこれらのプロジェクトをどう作って確認するか、リクエストに何を書くか、よくある問題について: Spigot and Paper plugins (Java or Kotlin)ガイド。