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