Paper 26.x support, update Gradle to 9.5.1, migrate deprecated APIs

[taranovegor]

Adds paper-helper-26x, a new helper module for Paper 26.x with Mojang mappings, using SerializableChunkData for thread-safe chunk access.
Paper 26.x requires paperweight 2.x, which requires Gradle 9. To support this:

• Gradle wrapper updated to 9.5.1; shadow plugin migrated to com.gradleup.shadow:9.4.2
• Deprecated Gradle APIs removed across all modules (archivesBaseName, sourceCompatibility, archivePath, jcenter())
• Fabric modules switched from shadow to bundle; Forge modules excluded from shadow (ForgeGradle 6.x is incompatible with Gradle 9)
• Spigot helper dependencies changed from implementation to runtimeOnly — loaded via reflection

java -version
openjdk version "25.0.3" 2026-04-21
OpenJDK Runtime Environment (build 25.0.3+9-2-deb13u1-Debian)
OpenJDK 64-Bit Server VM (build 25.0.3+9-2-deb13u1-Debian, mixed mode, sharing)

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by net.rubygrapefruit.platform.internal.NativeLibraryLoader in an unnamed module (file:/home/rat/.gradle/wrapper/dists/gradle-9.5.1-bin/iq79hdu3mqx29lgffhp8bfmx/gradle-9.5.1/lib/native-platform-0.22-milestone-29.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/9.5.1/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
Daemon will be stopped at the end of the build 

> Configure project :fabric-1.14.4
Fabric Loom: 1.15.5

> Configure project :fabric-1.15.2
Fabric Loom: 1.15.5

> Configure project :fabric-1.16.4
Fabric Loom: 1.15.5

> Configure project :fabric-1.17.1
Fabric Loom: 1.15.5

> Configure project :fabric-1.18.2
Fabric Loom: 1.15.5

> Configure project :fabric-1.19.4
Fabric Loom: 1.15.5

> Configure project :fabric-1.20.6
Fabric Loom: 1.15.5

> Configure project :fabric-1.21.11
Fabric Loom: 1.15.5

> Configure project :fabric-1.21.6
Fabric Loom: 1.15.5

> Configure project :fabric-1.21.9-10
Fabric Loom: 1.15.5

[Incubating] Problems report is available at: file:///home/rat/projects/taranovegor/dynmap/build/reports/problems/problems-report.html

Deprecated Gradle features were used in this build, making it incompatible with Gradle 10.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/9.5.1/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD SUCCESSFUL in 18s
172 actionable tasks: 2 executed, 170 up-to-date
Consider enabling configuration cache to speed up this build: https://docs.gradle.org/9.5.1/userguide/configuration_cache_enabling.html

ls target | xargs -n 1 basename
Dynmap-3.9-SNAPSHOT-fabric-1.14.4.jar
Dynmap-3.9-SNAPSHOT-fabric-1.14.4.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.15.2.jar
Dynmap-3.9-SNAPSHOT-fabric-1.15.2.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.16.4.jar
Dynmap-3.9-SNAPSHOT-fabric-1.16.4.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.17.1.jar
Dynmap-3.9-SNAPSHOT-fabric-1.17.1.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.18.2.jar
Dynmap-3.9-SNAPSHOT-fabric-1.18.2.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.19.4.jar
Dynmap-3.9-SNAPSHOT-fabric-1.19.4.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.20.6.jar
Dynmap-3.9-SNAPSHOT-fabric-1.20.6.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.21.11.jar
Dynmap-3.9-SNAPSHOT-fabric-1.21.11.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.21.6.jar
Dynmap-3.9-SNAPSHOT-fabric-1.21.6.jar.MD5
Dynmap-3.9-SNAPSHOT-fabric-1.21.9-10.jar
Dynmap-3.9-SNAPSHOT-fabric-1.21.9-10.jar.MD5
Dynmap-3.9-SNAPSHOT-spigot.jar
Dynmap-3.9-SNAPSHOT-spigot.jar.MD5
dynmap-api-3.9-SNAPSHOT.jar
DynmapCore-3.9-SNAPSHOT.jar
DynmapCoreAPI-3.9-SNAPSHOT.jar

[jacob1]

Awesome port! Lots of big changes around the codebase for gradle, but they are definitely necessary. Now that it uses official mappings + paperweight, I think the paper wrapper should work for most future versions, rarely needing changes.

The forge builds requiring gradle 8 is a bit weird. I see an announcement on their forums about ForgeGradle 7.x which should work with gradle 9. I don't build or use forge plugins though, no experience there. Wonder if it's even worth fixing, with NeoForge replacing Forge for modern MC versions.

[taranovegor]

Thanks! Keeping the Gradle 8 workaround for Forge for now is on purpose. I don't have a Forge setup to test the builds. It's probably worth opening a separate issue for the ForgeGradle 7.x migration, especially considering where NeoForge seems to be heading for newer MC versions.

[sfphoton]

26.2 came out recently and I noticed your PR could also be compatible with it (and potentially some future versions).

Currently, in spigot/src/main/java/org/dynmap/bukkit/Helper.java line 43 you explicitly check for the version 26.1. You could change it to something like else if (v.contains("(MC: 26.")) {.

I have tested this idea under Spigot and it seems to work.

[taranovegor]

Good point. Now that it's on official mappings + paperweight the helper isn't pinned to one minor version, so widening to 26. makes sense, thanks for testing it on 26.2. I'll get it in next time I'm on this. The next major should make things clearer, and this same approach might well carry over.

[Tsoccerguy3]

Good point. Now that it's on official mappings + paperweight the helper isn't pinned to one minor version, so widening to 26. makes sense, thanks for testing it on 26.2. I'll get it in next time I'm on this. The next major should make things clearer, and this same approach might well carry over.

i compiled your fork and had to add this updated
models_1.txt
to get this jar with updated blocks , for testing with Paper 26.2 build 23 .

[Tsoccerguy3]

Dynmap-3.9-SNAPSHOT-26.1-2.zip

[vpzomtrrfrt]

I'm unable to build this branch, getting this error:

* What went wrong:
A problem occurred configuring project ':paper-helper-26x'.
> Failed to notify project evaluation listener.
   > Unable to resolve a dev bundle, which is required for paperweight to function.
     Add a dev bundle to the 'paperweightDevelopmentBundle' configuration (the dependencies.paperweight extension can help with this), and ensure there is a repository to resolve it from (the Paper repository is used by default).

[Tsoccerguy3]

I'm unable to build this branch, getting this error:

* What went wrong:
A problem occurred configuring project ':paper-helper-26x'.
> Failed to notify project evaluation listener.
   > Unable to resolve a dev bundle, which is required for paperweight to function.
     Add a dev bundle to the 'paperweightDevelopmentBundle' configuration (the dependencies.paperweight extension can help with this), and ensure there is a repository to resolve it from (the Paper repository is used by default).

you need to compile the 26.x with JDK 25

[vpzomtrrfrt]

I am, otherwise it would have failed earlier

[Tsoccerguy3]

I am, otherwise it would have failed earlier

compile Paper and Spigot to local maven on your computer . Do gradlew tasks for commands ,edit settings.gradle for stuff you don't want . start with JDK21 then switch to JDK25 . you need to update the models+1.txt . or get the compiled jar above.

[Tsoccerguy3]

zipped jar
Dynmap-3.9-SNAPSHOT-26.1-2_spigot.jar.zip

zipped checksum
Dynmap-3.9-SNAPSHOT-26.1-2_spigot.jar.zip.sha256.zip

updated
models_1.txt
models_1.txt

texture_1.txt
texture_1.txt

[Schneidertm]

Thank you so much for your work! I really do appreciate it!

I did delete my whole world and a rerender after. Can someone might explain why there are certain black spots. I check them on the map the chunks are not deleted.

[Tsoccerguy3]

Thank you so much for your work! I really do appreciate it!

I did delete my whole world and a rerender after. Can someone might explain why there are certain black spots. I check them on the map the chunks are not deleted.

i think those are lighting errors get this plugin https://github.com/bergerhealer/Light-Cleaner , /tp to the center of the affected region and run the command .

[Tsoccerguy3]

then run a /radiusrender

[Schneidertm]

i think those are lighting errors get this plugin https://github.com/bergerhealer/Light-Cleaner , /tp to the center of the affected region and run the command .

Thanks so much! It worked

[blackfist666]

Thanks for this — it's the only thing making Dynmap usable on 26.x right now.

Two things I hit building it for a Paper 26.2 server, in case they're useful to you or anyone else building from this branch.

1. It doesn't compile against a 26.2 dev bundle

Bumping paperDevBundle from 26.1.2.build.69-stable to 26.2.build.112-stable fails:

MapChunkCache26x.java:40: error: loaded has private access in LevelChunk
    if (c == null || !c.loaded) {
                       ^
MapChunkCache26x.java:59: error: loaded has private access in LevelChunk
2 errors

LevelChunk.loaded was accessible in 26.1.2 but is private in 26.2 (build 112), with no public getter — only setLoaded(boolean).

ServerLevel.getChunkIfLoaded() already returns null unless the chunk is loaded, so the field check looks redundant and dropping it is enough:

LevelChunk c = cw.getHandle().getChunkIfLoaded(chunk.x, chunk.z);
if (c == null) {
    return Optional.empty();
}

Worth flagging that jars compiled against the 26.1.2 bundle still read that now-private field, so they may hit an IllegalAccessError on the loaded-chunk path when run on 26.2. I haven't reproduced that directly — my 26.1.2-built test jar ran fine for a while, so that path may just not get exercised often — but it seems worth avoiding either way.

2. No render data for 26.x blocks

A jar built from this branch alone has zero definitions for the new 26.x blocks — golden_dandelion, and the sulfur/cinnabar families from 26.2 — so they render as holes on the map. I only noticed by diffing my build against @Tsoccerguy3's, which is why I mention it.

@Tsoccerguy3's models_1.txt / texture_1.txt posted upthread fix this and work well. One caution if you're thinking of folding them in here: alongside the (correctly gated [26.1-] / [26.2-]) additions, the texture_1.txt also removes some legacy version-gated entries — [-1.16.5] grass_path and rail, [-1.20.2] grass, [-1.13.2] wall_sign — and switches all six leaf types from transparency=LEAVES to TRANSPARENT with no version gate. Harmless on a 26.x-only build, but it would change rendering on older servers in a single multi-version jar.

The models_1.txt side looks clean by comparison — the additions are all properly version-gated, plus a few genuine typo fixes (Vy=1,0 → Vy=1.0, [1-14-] → [1.14-], bell data=8d → data=8).

Build notes

For anyone stuck on "Unable to resolve a dev bundle": I didn't need BuildTools or a local Maven install. The org.spigotmc:spigot server jars the bukkit-helper-* modules need are mirrored at repo.mikeprimm.com, which is already in the root build.gradle repositories.

I also didn't need the JDK 21 → 25 switch — JDK 25 still accepts --release 8 (deprecation warning only), so a single pass worked:

JAVA_HOME=/path/to/jdk-25 ./gradlew :spigot:build

Verified running on Paper 26.2 build 112 / Java 25: plugin enables, web UI serves, all worlds render, no access errors in the log.

[taranovegor]

Thanks for the detailed writeup, @blackfist666.

On point 1: agreed. I'll take care of it soon and verify the build against the current versions.

On point 2: this PR was primarily focused on the build-side refactor for the new versions (Gradle 9, paperweight, the helper module itself), not on adding render data for new blocks, that's already covered by #4263.

@reusteur73, once I push the fix above, could you merge/rebase those changes on your side? Also curious what you think about moving the models_1.txt/texture_1.txt work into this PR instead, would that be a problem for you?

[reusteur73]

@reusteur73, once I push the fix above, could you merge/rebase those changes on your side? Also curious what you think about moving the models_1.txt/texture_1.txt work into this PR instead, would that be a problem for you?

Sure, I'll rebase on my side once you push the fix

No problem for me moving models_1.txt / texture_1.txt into this PR, just keep in mind there are also PNG textures involved, not just the text files (see commits bb4a2ba and ef24b4b)

Also I just noticed yesterday beds (any color) don't render on my map in 26.2 (Fabric). I'll look into it soon, might be better to wait a bit before merging until this gets fixed

[taranovegor]

@blackfist666, quick follow-up: point 1 is done and pushed - dev bundle bumped to 26.2.build.112-stable, and the loaded field access in MapChunkCache26x is removed. Builds clean on 26.2 and I've verified rendering works on a Paper 26.1 and 26.2 servers. Thanks you for detailed report 👍

Build of the current branch: Dynmap-3.9-SNAPSHOT-spigot.zip
A build containing commits bb4a2ba and ef24b4b from the comment above: Dynmap-3.9-SNAPSHOT-spigot.jar.zip

[Chevels]

@blackfist666, quick follow-up: point 1 is done and pushed - dev bundle bumped to 26.2.build.112-stable, and the loaded field access in MapChunkCache26x is removed. Builds clean on 26.2 and I've verified rendering works on a Paper 26.1 and 26.2 servers. Thanks you for detailed report 👍

Build of the current branch: Dynmap-3.9-SNAPSHOT-spigot.zip A build containing commits bb4a2ba and ef24b4b from the comment above: Dynmap-3.9-SNAPSHOT-spigot.jar.zip

Hello!
First of all, thanks for your work on Dynmap <3
Unfortunately, ever since I installed this version ("Build of the current branch") and ran /dynmap fullrender, the plugin has stopped working after the server reboot (the web interface shows nothing but a black screen), and the following message appears at startup:
[dynmap] Invalid rotate error - line 1642 of file: models_1.txt

I don't see any file with that name in my Dynmap folder. Can this issue be fixed on my end, or should I switch back to a different fork? It's a shame, because your version seems technically much better 😥

[reusteur73]

@blackfist666, quick follow-up: point 1 is done and pushed - dev bundle bumped to 26.2.build.112-stable, and the loaded field access in MapChunkCache26x is removed. Builds clean on 26.2 and I've verified rendering works on a Paper 26.1 and 26.2 servers. Thanks you for detailed report 👍
Build of the current branch: Dynmap-3.9-SNAPSHOT-spigot.zip A build containing commits bb4a2ba and ef24b4b from the comment above: Dynmap-3.9-SNAPSHOT-spigot.jar.zip

Hello! First of all, thanks for your work on Dynmap <3 Unfortunately, ever since I installed this version ("Build of the current branch") and ran /dynmap fullrender, the plugin has stopped working after the server reboot (the web interface shows nothing but a black screen), and the following message appears at startup: [dynmap] Invalid rotate error - line 1642 of file: models_1.txt

I don't see any file with that name in my Dynmap folder. Can this issue be fixed on my end, or should I switch back to a different fork? It's a shame, because your version seems technically much better 😥

You could try using one of the versions listed here: https://github.com/reusteur73/dynmap/releases/tag/26.1.fix1

It contains the fixes mentioned above, as well as a fix for bed rendering. Let me know if you run into any issues with it.

[Chevels]

@blackfist666, quick follow-up: point 1 is done and pushed - dev bundle bumped to 26.2.build.112-stable, and the loaded field access in MapChunkCache26x is removed. Builds clean on 26.2 and I've verified rendering works on a Paper 26.1 and 26.2 servers. Thanks you for detailed report 👍
Build of the current branch: Dynmap-3.9-SNAPSHOT-spigot.zip A build containing commits bb4a2ba and ef24b4b from the comment above: Dynmap-3.9-SNAPSHOT-spigot.jar.zip

Hello! First of all, thanks for your work on Dynmap <3 Unfortunately, ever since I installed this version ("Build of the current branch") and ran /dynmap fullrender, the plugin has stopped working after the server reboot (the web interface shows nothing but a black screen), and the following message appears at startup: [dynmap] Invalid rotate error - line 1642 of file: models_1.txt
I don't see any file with that name in my Dynmap folder. Can this issue be fixed on my end, or should I switch back to a different fork? It's a shame, because your version seems technically much better 😥

You could try using one of the versions listed here: https://github.com/reusteur73/dynmap/releases/tag/26.1.fix1

It contains the fixes mentioned above, as well as a fix for bed rendering. Let me know if you run into any issues with it.

Thanks a lot for your help. Unfortunately, I tested your build—as well as the one provided by taranovegor that included the two fixes—but in every case, I ran into a strange issue:
Everything seems to work fine until the full render of my overworld finishes. At that point, Dynmap becomes inaccessible; ; the page loads indefinitely, only the interface remains, but no matter which map is displayed, there is nothing—everything is black. I should mention that each time, I had to delete the following files:
dynmap.db
dynmap.db-shm
dynmap.db-wal
Heavy.pending (Heavy is the name of our overworld)

Otherwise, upon the next restart, Dynmap indicates "resuming full render..." during startup, but nothing actually resumes since it had already finished before the reboot. Plus, the web interface stops working.

I’ve been using Dynmap on my server for over 15 years and have never encountered this problem.
I don't want to be a bother, so I’m going to roll back to the first build supporting 26.1-2 that I installed a few weeks ago, hoping that sorts things out.

In any case, Pl3xmap is still working perfectly (I use it alongside Dynmap), and just to check, I tested Bluemap, which works correctly too. I’m not sure why Dynmap is struggling so much...

Regardless, thank you all for your work on developing Dynmap ❤

[Schneidertm]

@Chevels why would you run dynmap with storage type sqlite?

After solving the lighting issues mentioned above on one world I'm running extremely well in filetree storage-type. I'm about 10 GB with my biggest world 4000 radius rendered in flat and surface.

I'm extremely thankful for taranovegor and reusteur73 for this PR. Thank you so much!

[blackfist666]

@taranovegor @Chevels — I think there are two separate faults tangled together here, and only one of them belongs to this PR.

1. Invalid rotate error - line 1642 of file: models_1.txt

This is a four-year-old upstream typo that only becomes fatal on 26.x.

DynmapCore/src/main/resources/models_1.txt line 1640 reads:

[1-14-]modellist:id=campfire,data=12,data=13,data=14,data=15,box=...

That should be [1.14-]. It came in with f433454 (Jan 2022).

HDBlockModels.checkVersionRange splits the range on -, so 1-14- parses as low=1, high=14, and parseVersion weights the first component by 1e10. So the gate has always meant "MC 1 through 14" — which every 1.x version satisfied. On 26.2 the major is 26 > 14, and it evaluates false for the first time in four years.

The unlit-campfire modellist is therefore skipped, so the patchrotate on line 1642 looks up a model that was never built. That lands in the else at HDBlockModels.java:538:

else {
    Log.severe("Invalid rotate error - line " + lineNum + " of file: " + fname);
    return;
}

Note the return — it aborts the parse of the whole file at line 1642 of 4732, so 2,784 further model definitions never load, which is essentially every block model from 1.14 onward. It isn't a cosmetic warning.

The fix is one character:

-[1-14-]modellist:id=campfire,data=12,data=13,data=14,data=15,box=...
+[1.14-]modellist:id=campfire,data=12,data=13,data=14,data=15,box=...

I checked whether there were more of these: I evaluated every line-start version gate in models_0.txt, models_1.txt, texture_0.txt, texture_1.txt and biome_rainfall_temp.txt (138 distinct gates over 7,439 gated lines) against 1.21.11 and 26.2 using the real checkVersionRange/parseVersion/normalizeVersion semantics. [1-14-] is the only gate whose meaning changes. The hardcoded ranges in Java are all open-ended except 1.7.0-1.17.1 in BiomeMap, which already excluded 1.21.11. So it's a family of one.

@Chevels — worth knowing that this is still present in the build you were pointed at: reusteur73/dynmap 26.1.fix1 carries the same [1-14-] on line 1640 with the same three live patchrotate lines under it, so switching builds wouldn't have cleared that error.

Possibly worth a separate look: that return on line 540 could be a continue, as the sibling rotate branch at line 490 already does. One malformed line silently discarding 60% of the model file is a harsh failure mode, and it's what turned a dormant typo into a total loss of block models.

2. The black map after a fullrender — I don't think this is 26.x at all

@Chevels, your second report (black on every world, UI loads but nothing renders, Heavy.pending left behind, "resuming full render" that resumes nothing, cleared only by deleting dynmap.db* and the pending file) matches #3434 almost word for word. That was filed in July 2021 against 3.2-beta on MC 1.16.5, and is still open:

broken "ghost" tasks: tasks that get saved at the time of closing the server, regardless if they are actually finished or not. Those show up again every time the server restarts and either resume, or, if they are actually done, they complete instantly [...] But never get removed! [...] When one (or more) of those render tasks present, the web interface stops working altogether, all dimensions are black and no user skin shows up. If i delete those tasks manually, dynmap initializes properly and the web map works

And @VL4DST3R's follow-up on that issue names the trigger:

this is still an issue if using database storage. Recently I tested by switching to loose files to compare and contrast, and while the crashing/lockup reported here no longer happens...

You listed dynmap.db, dynmap.db-shm and dynmap.db-wal, so you're on SQLite storage. There's also #3720 — "Dynmap fails with large SQLite database using internal webserver or standalone" — closed, same territory.

So before rolling back any further, the thing I'd try is: switch storage/type in configuration.txt from sqlite to filetree, delete the leftover Heavy.pending, and re-run the fullrender. That's the workaround that was actually verified to stop the lockup, and it's independent of which 26.x build you're on.

To be straight about the limits of that: I have not reproduced it myself — my own server runs flat-file storage — so this is pattern-matching your report onto an existing issue, not a diagnosis from a repro. If it does still happen on filetree, that's genuinely new information and worth saying so here, because it would mean #3434 has a second cause.

One theory I chased and ruled out

I first suspected the unreleased post-3.8 commits sitting on v3.0 — the ones rewriting IsoHDPerspective, TexturePack and cutting a net 95 lines out of ShadowHDLighting. Anyone building this branch gets them and no release does, which fit "never seen this in 15 years" nicely. Having read the diffs, I don't think they're implicated: the dropped defLightingTable != null guard is dead code (the field is final and assigned in the constructor), the incremental top/direction hoist in IsoHDPerspective.render() is algebraically exact because Matrix3D is a pure linear 3×3 with no translation term, and the suspicious-looking TexturePack changes are either in the OBJ-export path or are dead stores. Recording that so nobody else spends an evening on it.

@taranovegor — thanks for the quick turnaround on the dev bundle bump and the loaded field access; both confirmed good here on Paper 26.2.