--- title: "Minecraft-Plugin von 1.21 auf 26.x migrieren: Leitfaden 2026 | Minax" description: "Kalender-Versionen, Adventure 5, der verschwundene Remapper, libraries statt Shading: alles was du ändern musst, um ein Plugin von 1.21 auf 26.x zu bringen, und welche Version du wirklich anvisieren solltest." lang: de-DE json-ld: | [ { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://minax.fun/#organization", "name": "Minax", "url": "https://minax.fun", "logo": { "@type": "ImageObject", "url": "https://minax.fun/minax-logo-256.png", "width": 256, "height": 256 }, "description": "Plateforme IA pour créer des plugins Minecraft (Paper, Spigot, Bukkit, Folia) sans coder en Java." }, { "@type": "WebSite", "@id": "https://minax.fun/#website", "url": "https://minax.fun", "name": "Minax", "publisher": { "@id": "https://minax.fun/#organization" }, "inLanguage": [ "fr-FR", "en-US", "de-DE" ], "potentialAction": { "@type": "SearchAction", "target": "https://minax.fun/discover?q={search_term_string}", "query-input": "required name=search_term_string" } } ] }, [ { "@context": "https://schema.org", "@type": "Article", "headline": "Minecraft-Plugin von 1.21 auf 26.x migrieren: der komplette Leitfaden", "description": "Minecraft nutzt jetzt Kalender-Versionen. Was du in einem Plugin konkret ändern musst, um von 1.21 auf 26.x zu kommen, und welche Version du angesichts der echten Server-Verteilung wirklich anvisieren solltest.", "image": "https://minax.fun/og-image.jpg", "datePublished": "2026-07-25", "dateModified": "2026-07-25", "inLanguage": "de", "author": { "@type": "Organization", "name": "Minax", "url": "https://minax.fun" }, "publisher": { "@type": "Organization", "name": "Minax", "url": "https://minax.fun" }, "mainEntityOfPage": "https://minax.fun/blog/minecraft-plugin-auf-neue-version-migrieren" }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Soll ich 1.21 aufgeben, jetzt wo 26.2 da ist?", "acceptedAnswer": { "@type": "Answer", "text": "Nein. In einer bStats-Erhebung mit 62.948 Servern liegt 1.21.11 bei 36,4 % und 1.21.4 immer noch bei 7,2 %, gegenüber 14,9 % für 26.1.2 und 7,4 % für 26.2. Die 1.21-Familie ist weiter die Mehrheit, du verlierst also mehr Server, als du gewinnst." } }, { "@type": "Question", "name": "Muss ich für Kalender-Versionen mit Java 25 kompilieren?", "acceptedAnswer": { "@type": "Answer", "text": "Java 25 ist die Laufzeit-Untergrenze der Kalender-Versionen, aber Java 21 bleibt das richtige Kompilier-Ziel: ein mit Java 21 gebautes .jar lädt auf einer neueren Laufzeit, ein mit Java 25 gebautes .jar verweigert auf einem Java-21-Server den Start mit UnsupportedClassVersionError." } }, { "@type": "Question", "name": "Warum kompiliert mein Nachrichten-Code auf Paper 26.x nicht mehr?", "acceptedAnswer": { "@type": "Answer", "text": "Paper 26.x bringt Adventure 5 mit, und Adventure 5 hat APIs entfernt, die vorher nur als veraltet markiert waren. Betroffen ist alles, was mit Nachrichten und angezeigtem Text zu tun hat. Der saubere Ausweg ist Component überall, das kompiliert auch auf 1.21." } }, { "@type": "Question", "name": "Muss ich den SQLite-Treiber weiter ins .jar packen?", "acceptedAnswer": { "@type": "Answer", "text": "Nein, der SQLite-JDBC-Treiber wird von Paper schon mitgeliefert. HikariCP dagegen nicht: deklariere es im libraries-Block der plugin.yml, statt es zu shaden." } } ] }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://minax.fun/blog" }, { "@type": "ListItem", "position": 2, "name": "Plugin auf eine neue Version migrieren", "item": "https://minax.fun/blog/minecraft-plugin-auf-neue-version-migrieren" } ] } ] ] --- [Zum Inhalt springen](#main-content) [Minax](/) 14 online [Plugins](/discover)[Blog](/blog)[Preise](/pricing) de AnmeldenRegistrieren [Blog](/blog)/ Migration 25\. Juli 2026 · Migration # Plugin von 1.21 auf 26.x migrieren: was kaputtgeht, und was du wirklich anvisieren solltest ![Minecraft-Server-Konsole während der Migration eines Plugins auf eine Kalender-Version](/assets/blog-minecraft-update-DQC6XZwv.webp) Minecraft zählt nicht mehr in 1.x. Die aktuelle Version heißt 26.2 und ist am 16. Juni 2026 erschienen. Wenn du ein Plugin pflegst, das für 1.21 geschrieben wurde, ist die spannende Frage nicht nur technisch, sondern strategisch. Eine Migration kostet Zeit, und die falsche Zielversion kostet Installationen. Dieser Leitfaden zeigt dir, was du im Code änderst, in welcher Reihenfolge, und vor allem welche Version du anvisieren solltest. Die richtige Antwort ist nicht die neueste. ## Was die Kalender-Versionierung wirklich verändert Die Versionsnummer codiert jetzt das Jahr und den Rang der Veröffentlichung in diesem Jahr. 26.2 heißt zweite Version aus 2026, nicht mehr. Die Nummer sagt dir nicht mehr, ob eine Änderung kosmetisch oder strukturell ist, und genau das ist der erste Reflex, den du ablegen musst: aus dem Nummernsprung lässt sich der Umfang einer Migration nicht mehr ableiten. Du musst schauen, was darunter passiert ist. Darunter haben sich drei Dinge bewegt, und alle drei sind wichtig. Minecraft ist seit 26.1 deobfuskiert, damit ist der Remapper von Paper verschwunden. Paper 26.x bringt Adventure 5 mit, das APIs entfernt hat, die vorher nur als veraltet markiert waren. Und Java 25 ist die Laufzeit-Untergrenze der Kalender-Versionen geworden. Ein 1.21-Plugin, das einen dieser drei Bereiche berührt, lässt sich nicht einfach neu kompilieren. Die Zahl, die fast niemand vor der Migration prüft In einer bStats-Erhebung über **62.948 Server** sieht die echte Verteilung so aus: 1.21.11 bei **36,4 %**, 26.1.2 bei **14,9 %**, 26.2 bei **7,4 %**, 1.21.4 bei **7,2 %**. Diese beiden 1.21-Einträge allein machen 43,6 % des Bestands aus, gegenüber 22,3 % für beide Kalender-Zweige zusammen. Im Bestand ist 1.21 also fast doppelt so stark vertreten wie die Kalender-Versionen. [bStats](https://bstats.org) veröffentlicht diese Verteilungen laufend, und es ist die einzige ernsthafte Messung, die es gibt. ## Welche Version du wirklich anvisieren solltest Es gibt noch eine Falle. Paper 26.2 hat keinen stabilen Build: das sinnvolle Produktions-Ziel im Kalender-Zweig ist 26.1.2, nicht 26.2. Ein Plugin, das es nur für 26.2 gibt, verlangt von deinen Nutzern eine Basis, die Paper selbst nicht als stabil bezeichnet. Anteil am Bestand Bewertung 1.21.11 36,4 % Hauptziel, hier liegen die meisten Installationen 26.1.2 14,9 % Kalender-Ziel für Produktion, hier testen 26.2 7,4 % Kein stabiler Paper-Build, nicht allein dafür bauen 1.21.4 7,2 % Kompatibel ohne Aufwand, solange du auf der öffentlichen API bleibst Meine Einschätzung, klar gesagt: 1.21 heute aufzugeben wäre ein Fehler. Das ist keine Nostalgie, das ist Mathematik. Du würdest die Familie aufgeben, die die Mehrheit stellt, um einen Zweig zu gewinnen, der halb so viel wiegt und dessen neueste Version nicht einmal einen stabilen Build hat. Das richtige Ziel ist ein einziges Plugin, das gegen 1.21 kompiliert, auf 26.x lädt und nichts benutzt, was dazwischen verschwunden ist. > "Du migrierst nicht auf die neueste Version. Du migrierst auf die Version, die deine Nutzer wirklich laufen lassen." > > **Migrations-Regel**, gilt für das ganze Bukkit-Ökosystem ## API-Version und Java-Version Zwei getrennte Einstellungen, die ständig verwechselt werden. Die API-Version ist die Generation der Bukkit-API, gegen die dein Code geschrieben ist, deklariert in plugin.yml. Die Java-Version ist das Bytecode-Format, das dein Compiler ausgibt. Beide setzt du unabhängig voneinander, und die zweite falsch zu setzen ist der banalste Grund, warum ein Plugin nicht lädt. pom.xml ``` 21 UTF-8 papermc https://repo.papermc.io/repository/maven-public/ io.papermc.paper paper-api 1.21.11-R0.1-SNAPSHOT provided ``` Kompiliere gegen die _älteste_ Version, die du unterstützen willst, nicht gegen die neueste. Ein Plugin, das gegen die 26.x-API kompiliert wurde und auf einem 1.21-Server landet, stirbt in dem Moment, in dem es eine Methode aufruft, die es dort noch nicht gibt. Umgekehrt läuft ein gegen 1.21 kompiliertes Plugin auf 26.x, solange es keine entfernte API benutzt. Diese Asymmetrie arbeitet für dich. Die genauen Koordinaten pro Zweig findest du auf [docs.papermc.io](https://docs.papermc.io), die Signaturen auf [jd.papermc.io](https://jd.papermc.io). Java 25 ist eine Laufzeit-Untergrenze, kein Kompilier-Ziel Java 25 ist die Untergrenze der Kalender-Versionen. Das heißt, ein 26.x-Server läuft auf Java 25 oder neuer, nicht dass dein Plugin für 25 kompiliert sein muss. Wenn du dein Kompilier-Ziel auf 25 setzt, verweigert dein .jar auf der gesamten 1.21-Familie den Start, die noch auf Java 21 läuft, mit einem `UnsupportedClassVersionError` als Quittung. Bleib bei 21, außer du brauchst wirklich ein bestimmtes Sprach-Feature, und das ist in einem Plugin selten. ## Adventure 5: Text ist die Bruchstelle Hier entsteht der meiste Schaden. Paper 26.x bringt Adventure 5 mit, und Adventure 5 hat APIs entfernt, die bis dahin nur als veraltet markiert waren. Der betroffene Bereich ist vorhersehbar: alles rund um Nachrichten und Text, der Spielern angezeigt wird. Ein 1.21-Plugin, das seine Nachrichten auf die alte Art verschickt, kompiliert unter Umständen einfach nicht mehr. Die gute Nachricht: es gibt genau einen Ausweg, und der funktioniert in beiden Welten. Adventure ist schon lange in Paper enthalten, also kompiliert Code mit `Component` sowohl auf 1.21 als auch auf 26.x. Du pflegst keine zwei Versionen, du modernisierst einmal. Java ``` package fun.example.migration; import net.kyori.adventure.text.Component; import net.kyori.adventure.text.format.NamedTextColor; import net.kyori.adventure.text.minimessage.MiniMessage; import net.kyori.adventure.text.serializer.legacy.LegacyComponentSerializer; public final class Messages { private static final MiniMessage MINI = MiniMessage.miniMessage(); private Messages() { } /** Im Code gebaut, ganz ohne Farb-Zeichenketten. */ public static Component welcome(String playerName) { return Component.text("Willkommen ", NamedTextColor.GOLD) .append(Component.text(playerName, NamedTextColor.WHITE)) .append(Component.text(" auf dem Server.", NamedTextColor.GRAY)); } /** Gleiches Prinzip für eine Zahl, ohne gefärbte Verkettung. */ public static Component balance(long amount) { return Component.text("Guthaben: ", NamedTextColor.GRAY) .append(Component.text(amount, NamedTextColor.GOLD)); } /** Zeile, die der Admin in die config.yml geschrieben hat, im MiniMessage-Format. */ public static Component fromConfig(String line) { return MINI.deserialize(line); } /** * Alte Zeichenkette aus einer frühen config.yml, etwa "&aGrüner Text". * Umwandeln statt wegwerfen: diese Dateien existieren auf echten Servern * schon, und niemand schreibt sie von Hand neu. */ public static Component fromLegacy(String stored) { return LegacyComponentSerializer.legacyAmpersand().deserialize(stored); } } ``` An der Aufrufstelle brauchst du nichts Trickreiches: `player.sendMessage(Messages.welcome(player.getName()))`. Die Adventure-Dokumentation liegt auf [docs.advntr.dev](https://docs.advntr.dev), die Paper-Seite der Integration auf [docs.papermc.io](https://docs.papermc.io). Was nicht funktioniert: Suchen und Ersetzen Die Versuchung ist, mechanisch durch alle Nachrichten-Aufrufe zu gehen, bis der Compiler still ist. Zwei klassische Schäden. Erstens: du löschst das Einlesen der alten Zeichenketten aus der `config.yml`, und jeder Server, der seine Nachrichten angepasst hatte, verliert sie beim ersten Start. Zweitens: du übersiehst die Stellen, die weiter kompilieren, aber im Spiel anders aussehen, etwa Item-Namen, Inventar-Titel und Scoreboard-Zeilen. Geh diese drei Bereiche von Hand durch, bevor du den Code anfasst. ## Der Remapper ist verschwunden Minecraft ist seit 26.1 deobfuskiert, und mit der Obfuskierung ist der Remapper von Paper verschwunden. Wenn dein Plugin brav auf der öffentlichen Bukkit- und Paper-API geblieben ist, merkst du davon überhaupt nichts. Wenn es dagegen in die internen Server-Klassen hinuntergegriffen hat, trifft dich dieser Teil frontal: der Remapping-Schritt, auf dem dein Build aufbaute, existiert nicht mehr, und die Namen, über die du reflektiert hast, sind nicht mehr dieselben. Mein Rat ist unbequem und ich stehe dazu: nimm die Migration als Anlass, aus den Interna herauszukommen. Reflexion auf interne Klassen ist genau die Art Code, die bei jeder Version eine Korrektur verlangt, Kalender oder nicht. Meistens macht die öffentliche API inzwischen dasselbe. Wenn das wirklich nicht reicht, kapsle diesen Zugriff in einer einzigen Klasse, mit einem sauberen Fallback, falls die erwartete Klasse fehlt, statt ihn im Plugin zu verstreuen. Was die Deobfuskierung bringt Kein Remapping-Schritt mehr im Build Lesbare Stacktraces in Fehlerberichten Lesbare Interna, wenn du ein Verhalten verstehen musst Was sie kaputt macht Builds, die auf den Remapper setzten, laufen nicht mehr Reflexion auf alte obfuskierte Namen scheitert Jedes NMS-Tutorial von vor 26.1 ist veraltet ## Der libraries-Block statt Shading Der historische Reflex war, Abhängigkeiten ins .jar zu packen, also zu shaden. Der `libraries:`\-Block in plugin.yml ersetzt diese Praxis: du deklarierst die Abhängigkeit, und der Server lädt sie selbst herunter. Das .jar wird wieder klein und enthält nur deinen Code. Bevor du irgendwas deklarierst, prüfe, was schon da ist. Der SQLite-JDBC-Treiber wird von Paper schon mitgeliefert. Wenn du ihn eingepackt hast, hast du Gewicht ohne Gegenwert bezahlt. HikariCP dagegen wird nicht mitgeliefert. Genau für solche Abhängigkeiten gibt es `libraries:`. plugin.yml ``` name: MeinPlugin version: 1.0.0 main: fun.example.migration.MeinPlugin api-version: '1.21' description: Migriertes Plugin, ein .jar für 1.21 und 26.x authors: [ MeinName ] # Wird vom Server beim ersten Start heruntergeladen. # Der SQLite-Treiber steht NICHT hier: Paper liefert ihn schon mit. libraries: - com.zaxxer:HikariCP:5.1.0 commands: guthaben: description: Zeigt dein Guthaben usage: /guthaben ``` Der Wert von `api-version` deklariert die API-Generation, gegen die dein Code geschrieben ist. Lass ihn auf der ältesten Generation, die du wirklich unterstützt: so bleibst du auf der ganzen 1.21-Familie ladbar und wirst von neueren Servern trotzdem akzeptiert. Das Dateiformat ist auf [docs.papermc.io](https://docs.papermc.io) dokumentiert und, für den historischen Bukkit-Teil, auf [hub.spigotmc.org](https://hub.spigotmc.org). Was nicht funktioniert: glauben, libraries sei kostenlos Zwei sehr konkrete Fallen. Erstens läuft der Download auf der Server-Maschine beim ersten Start: ein Hoster, der ausgehenden Netzwerk-Verkehr blockiert, lässt dein Plugin scheitern, und der Nutzer wird nicht verstehen, warum. Zweitens ist eine falsch geschriebene Koordinate beim Kompilieren unsichtbar. Dein Build läuft durch, dein .jar ist gültig, und der Fehler zeigt sich erst beim Start des Servers deines Nutzers. Teste das .jar immer auf einem echten Server, bevor du es veröffentlichst, nicht nur in der IDE. ## Die UUID-Falle im Offline-Modus Jetzt kommt der Teil, den fast kein Migrations-Leitfaden behandelt, und es ist der, der die meisten Daten zerstört. **75,1 % der Server laufen im Offline-Modus.** Im Offline-Modus wird die UUID eines Spielers aus seinem Namen abgeleitet. Das ist kein Implementierungsdetail, das ist eine Eigenschaft, die deinen Datenbank-Entwurf ändert: wenn der Spieler seinen Namen ändert, oder wenn der Server eines Tages in den Online-Modus wechselt, ändert sich der Schlüssel und alle Daten unter der alten UUID sind verwaist. Konkret liefert ein Wirtschafts-Plugin, das ein Guthaben nur an der UUID festmacht, seinen Nutzern dieses Szenario: der umbenannte Spieler verliert sein Geld, der Admin versteht nicht, was passiert ist, und niemand kann die Zuordnung rekonstruieren. Die Korrektur ist eine Spalte: speichere den Namen neben der UUID, indexiere ihn, und du behältst einen Rückweg. SQL ``` CREATE TABLE IF NOT EXISTS player_data ( uuid TEXT PRIMARY KEY, last_name TEXT NOT NULL, balance INTEGER NOT NULL DEFAULT 0, updated_at INTEGER NOT NULL ); -- Im Offline-Modus Pflicht: der einzige Rückweg, wenn ein Spieler sich -- umbenennt oder der Server in den Online-Modus wechselt. CREATE INDEX IF NOT EXISTS idx_player_data_name ON player_data(last_name); ``` Java ``` package fun.example.migration; import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; import java.util.UUID; public final class PlayerRepository { private final Connection connection; public PlayerRepository(Connection connection) { this.connection = connection; } /** * Schreibe den aktuellen Namen immer zusammen mit den Daten. * Ohne diese Zeile wird der Datensatz nach einer Umbenennung * unerreichbar, auf 75,1 % der Server im Offline-Modus. */ public void save(UUID uuid, String name, long balance) throws SQLException { String sql = "INSERT INTO player_data(uuid, last_name, balance, updated_at) " + "VALUES(?, ?, ?, ?) " + "ON CONFLICT(uuid) DO UPDATE SET " + "last_name = excluded.last_name, " + "balance = excluded.balance, " + "updated_at = excluded.updated_at"; try (PreparedStatement ps = connection.prepareStatement(sql)) { ps.setString(1, uuid.toString()); ps.setString(2, name); ps.setLong(3, balance); ps.setLong(4, System.currentTimeMillis()); ps.executeUpdate(); } } public long readBalance(UUID uuid) throws SQLException { String sql = "SELECT balance FROM player_data WHERE uuid = ?"; try (PreparedStatement ps = connection.prepareStatement(sql)) { ps.setString(1, uuid.toString()); try (ResultSet rs = ps.executeQuery()) { return rs.next() ? rs.getLong(1) : 0L; } } } } ``` Der Test, den ich jedes Mal mache Auf einem Test-Server im Offline-Modus: einloggen, Daten anlegen, ausloggen, den Test-Account umbenennen, wieder einloggen. Wenn deine Daten weg sind, ist dein Schema fragil, und das war es schon vor der Migration. Der Test dauert zwei Minuten und deckt einen Fehler auf, den drei Viertel des Bestands auslösen können. ## Folia: der Haupt-Thread ist nicht mehr garantiert Folia führt die Regionen der Welt auf mehreren Threads aus. Ein Plugin, das einen einzigen Haupt-Thread voraussetzt, wird nicht langsamer, es stürzt ab. Die Migration heißt: über den RegionScheduler gehen, wenn du die Welt anfasst, und Datenbank-Zugriffe nie auf einem Spiel-Thread laufen lassen, sonst sinken die TPS. Java ``` import org.bukkit.Bukkit; import org.bukkit.Location; import org.bukkit.entity.Player; import org.bukkit.plugin.Plugin; import java.sql.SQLException; import java.util.UUID; public final class BalanceLookup { private final Plugin plugin; private final PlayerRepository repository; public BalanceLookup(Plugin plugin, PlayerRepository repository) { this.plugin = plugin; this.repository = repository; } public void showBalance(UUID uuid, Location location) { // 1. Die Datenbank, abseits jedes Spiel-Threads. Bukkit.getAsyncScheduler().runNow(plugin, task -> { final long balance; try { balance = repository.readBalance(uuid); } catch (SQLException e) { plugin.getLogger().warning("Guthaben nicht lesbar: " + e.getMessage()); return; } // 2. Zurück in die Welt, auf dem Thread, der diese Region besitzt. Bukkit.getRegionScheduler().execute(plugin, location, () -> { Player player = Bukkit.getPlayer(uuid); if (player != null) { player.sendMessage(Messages.balance(balance)); } }); }); } } ``` Dieser Code ist nicht Folia-exklusiv: Paper stellt diese Scheduler bereit, du kannst ihn also schon jetzt gegen dein 1.21-Ziel schreiben und bleibst kompatibel, ohne eine zweite Codebasis. Das Verhalten von Folia ist auf [docs.papermc.io](https://docs.papermc.io) dokumentiert, und wenn du das Ergebnis sehen willst, ohne die Umgebung aufzusetzen, gibt unser [Folia-Plugin-Generator](/folia-plugin-erstellen) direkt RegionScheduler-Code aus. ## Meine Empfehlung, klar gesagt Ein neutraler Rundumblick hilft niemandem, also hier ist, was ich empfehle. **Ein .jar für die große Mehrheit der Fälle.** Kompiliert für Java 21, gegen die 1.21-API, kein Zugriff auf Interna, Adventure überall, Folia-kompatible Scheduler. Dieses Plugin deckt die 1.21-Familie ab, die die Mehrheit stellt, und lädt auf 26.x. Zwei getrennte Builds sind nur dann gerechtfertigt, wenn du wirklich die internen Server-Klassen anfasst. **Folia: auf einem kleinen Server migriere ich nicht.** Der RegionScheduler macht den Code schwerer lesbar, für einen Gewinn, den du nicht messen wirst, solange eine einzige Region alle trägt. Auf einem gut besuchten Server, oder auf einer sehr weitläufigen Karte mit verstreuten Spielern, lohnt sich die Investition. Schreib den kompatiblen Code trotzdem von Anfang an: auf Paper kostet er nichts und erspart dir die Umschreibung an dem Tag, an dem sich dein Maßstab ändert. **Datenbank: SQLite, solange du einen einzigen Server hast.** Der Treiber ist schon da, eine Verbindung reicht, und du deklarierst gar nichts. An dem Tag, an dem mehrere Server dieselben Daten teilen müssen, wechselst du zu MySQL, und erst dann gehört HikariCP in den `libraries:`\-Block. Ein Verbindungs-Pool auf einer lokalen SQLite-Datei ist Komplexität ohne Zweck. **26.2: dafür liefere ich nichts aus.** Solange es keinen stabilen Paper-Build gibt, ist das Kalender-Ziel 26.1.2. Teste auf 26.2 aus Neugier, aber bau deine Kompatibilität nicht darauf auf. ### Die Migration, ohne jede Zeile selbst zu lesen Beschreibe dein Plugin und die Zielversion. Minax schreibt Adventure-basierten Code, kompiliert ein sauberes .jar und lässt dich es online testen, bevor du es installierst. [Plugin migrieren](/minecraft-plugin-erstellen) ## Die Migrations-Checkliste, in dieser Reihenfolge 1. Ziel festlegen: gegen 1.21 kompilieren, Laden auf 26.1.2 prüfen. 2. Prüfen, dass `maven.compiler.release` auf 21 steht, nicht auf 25. 3. Alle Stellen auflisten, die Text erzeugen: Nachrichten, Item-Namen, Inventar-Titel, Scoreboards. 4. Diese Stellen auf `Component` umstellen und eine Umwandlung für alte config.yml-Zeichenketten ergänzen. 5. Jeden Zugriff auf interne Server-Klassen suchen, dann löschen oder in einer Klasse kapseln. 6. Alles aus dem .jar entfernen, was Paper schon liefert, angefangen beim SQLite-JDBC-Treiber. 7. Den Rest in `libraries:` deklarieren statt zu shaden. 8. Alle Datenbank-Zugriffe aus den Spiel-Threads herausziehen. 9. Annahmen über einen einzigen Haupt-Thread durch den RegionScheduler ersetzen. 10. Die Namens-Spalte neben die UUID legen und den Umbenennungs-Test im Offline-Modus machen. 11. Das .jar auf einem echten Server installieren, einmal auf 1.21 und einmal auf 26.1.2, bevor du es veröffentlichst. Wenn ein Schritt schiefgeht, lies die erste Fehlerzeile und sonst nichts: unser [Leitfaden zur Fehlersuche bei Plugins](/blog/erreurs-plugin-minecraft) deckt genau die Meldungen ab, die so eine Migration produziert. ## Fazit Die Kalender-Versionierung hat die Frage nach der Zielversion sichtbarer gemacht, nicht einfacher. Die echte Arbeit steckt in vier Baustellen: Text über Adventure, raus aus den Interna, Abhängigkeiten deklarieren statt einpacken, und die Annahme eines einzigen Threads aufgeben. Alles andere ist Feinjustierung. Und die wichtigste Entscheidung ist nicht technisch: solange 1.21 fast doppelt so viel wiegt wie der Kalender-Bestand, bleibt 1.21 die Zielversion, mit Code, der auch auf 26.x läuft. Was sich auf der Versionsseite geändert hat, steht ausführlich auf unserer Seite zu [Minecraft-26-Plugins](/minecraft-26-plugins-erstellen). ## Articles connexes [ ![Minecraft-26-Plugins: was sich ändert](/assets/blog-minecraft-update-DQC6XZwv.webp) Versionen ### Minecraft-26-Plugins: was sich ändert Lire ](/minecraft-26-plugins-erstellen)[ ![Mein Plugin lädt nicht: Fehlersuche](/assets/blog-optimiser-serveur-D9PGend8.webp) Fehlersuche ### Mein Plugin lädt nicht: Fehlersuche Lire ](/blog/erreurs-plugin-minecraft)[ ![Folia-Plugin erstellen](/assets/blog-create-plugin-1g5qWpiS.webp) Tool ### Folia-Plugin erstellen Lire ](/folia-plugin-erstellen) 12 Min. Lesezeit Sommaire [Kalender-Versionierung](#calendrier)[Welche Version anvisieren](#parc)[API-Version und Java](#api)[Adventure 5 und Text](#adventure)[Der Remapper ist weg](#remapper)[libraries statt Shading](#libraries)[Die UUID-Falle im Offline-Modus](#uuid)[Folia und der Haupt-Thread](#folia)[Meine Empfehlung](#avis)[Die Migrations-Checkliste](#checklist)[Fazit](#conclusion) Partager Lien[X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fminax.fun%2Fblog%2Fminecraft-plugin-auf-neue-version-migrieren) Minax Die spezialisierte KI, die das Erstellen von Minecraft-Plugins neu erfindet. Verwandle deine Ideen in wenigen Minuten in professionellen Code. **408** Erstellte Plugins **0** Mitglieder #### Produkt - [Plugin-Generator](/) - [Plugin erstellen](/creer-plugin-minecraft) - [Spigot-Generator](/generateur-spigot) - [Nutzerbewertungen](/discover) #### Ressourcen - [Blog & Ressourcen](/blog) - [Minecraft-Server-Guide](/guide-serveur-minecraft) - [Server hosten](/hebergeur-serveur-minecraft) - [SMP-Mechaniken](/smp-plugins-erstellen) - [Discord-Community](https://discord.gg/NG4nR3E5a6) - Kontakt #### Folge uns [Minax auf LinkedIn ](https://www.linkedin.com/in/thomas-bidaultt)[Minax auf Discord ](https://discord.gg/NG4nR3E5a6)[Minax auf YouTube ](https://www.youtube.com/@MrFrosasi)[Minax auf Instagram ](https://www.instagram.com/ccsglobal.inc) © 2026 Minax. Alle Rechte vorbehalten. [Datenschutz](/privacy)[Nutzungsbedingungen](/terms)[AGB](/cgv)[Cookies](/cookies)[Impressum](/legal)Cookies verwalten Start Entdecken Erstellen Projekte Profil Nous utilisons **Google Analytics**, **Microsoft Clarity** et **Reddit Pixel** pour analyser l'utilisation du site et améliorer votre expérience. [En savoir plus](/cookies) Tout refuserTout accepter