Userdev patches fail to apply in Java 19 due to FF output changing

[virustotalop]

I'm having an issue with using paperweight userdev with Java 19, the same project with Java 17 works fine but the patches will not apply when using Java 19. The same command also fails when running the command with command prompt. I have tested on two different Windows 10 machines with the same outcome. Test project: https://github.com/virustotalop/paperweight_java19_test Errors: https://gist.github.com/virustotalop/37cc6f337195388ef8be9983b503f91b

[electronicboy]

Probably a duplicate of #50

[SirYwell]

This happens on WSL2 (Ubuntu 20.04, Linux FS) too. Works fine with Java 17 and Java 18, but fails on Java 19. I doubt it is caused by file path length, especially as running ./gradlew build -Dpaperweight.debug=true logs other patches with longer paths that seem to apply just fine.

[electronicboy]

https://gist.github.com/00cba28861d109f4f89e027b789232db

Looks like the decompiler is producing different outputs across java versions

[zml2008]

Can you confirm whether that's a spigot-decompiled file of a FF-decompiled file? it it's FF open an issue over there and I'll take a look at it

[jpenilla]

decompile diff courtesy of cat, only FF is used in userdev

diff --git a/17/net/minecraft/world/level/border/WorldBorder.java b/19/net/minecraft/world/level/border/WorldBorder.java
index 28fd83b..0dff02b 100644
--- a/17/net/minecraft/world/level/border/WorldBorder.java
+++ b/19/net/minecraft/world/level/border/WorldBorder.java
@@ -15,7 +15,7 @@ import net.minecraft.world.phys.shapes.Shapes;
 import net.minecraft.world.phys.shapes.VoxelShape;

 public class WorldBorder {
-    public static final double MAX_SIZE = 5.9999968E7D;
+    public static final double MAX_SIZE = (double)5.999997E7F;
     public static final double MAX_CENTER_COORDINATE = 2.9999984E7D;
     private final List<BorderChangeListener> listeners = Lists.newArrayList();
     private double damagePerBlock = 0.2D;
@@ -25,8 +25,8 @@ public class WorldBorder {
     private double centerX;
     private double centerZ;
     int absoluteMaxSize = 29999984;
-    private WorldBorder.BorderExtent extent = new WorldBorder.StaticBorderExtent(5.9999968E7D);
-    public static final WorldBorder.Settings DEFAULT_SETTINGS = new WorldBorder.Settings(0.0D, 0.0D, 0.2D, 5.0D, 5, 15, 5.9999968E7D, 0L, 0.0D);
+    private WorldBorder.BorderExtent extent = new WorldBorder.StaticBorderExtent((double)5.999997E7F);
+    public static final WorldBorder.Settings DEFAULT_SETTINGS = new WorldBorder.Settings(0.0D, 0.0D, 0.2D, 5.0D, 5, 15, (double)5.999997E7F, 0L, 0.0D);

     public boolean isWithinBounds(BlockPos pos) {
         return (double)(pos.getX() + 1) > this.getMinX() && (double)pos.getX() < this.getMaxX() && (double)(pos.getZ() + 1) > this.getMinZ() && (double)pos.getZ() < this.getMaxZ();

[SirYwell]

This is probably caused by https://bugs.openjdk.org/browse/JDK-8291475

[jpenilla]

https://github.com/MinecraftForge/ForgeFlower/issues/130

[zml2008]

Thanks for the report - as an immediate workaround you could probably just run FF with the toolchain used by the server itself

[jpenilla]

If anything it might make sense to add a separate java launcher property for userdev setup from the project toolchain, but super low priority, for now users will just need to deal with using a <=18 toolchain for their project until this is fixed in FF. If you need 19 for compile, you can set a specific launcher to the compile task.

[virustotalop]

Setting the Java 19 toolchain for compile seems to work fine while the main toolchain is on Java 17. Thank you for the workaround!

[jpenilla]

https://github.com/PaperMC/Paper/commit/a172880e7d76e4ae5afb55df3d0fd24cfcc70c3f