Startup Issue with Minecraft - The server crashed and now has a java compile error

System Information

Field Value
Operating System Linux - Debian GNU/Linux 11 on x86_64
Product AMP ‘Decadeus’ v2.4.6.6 (Mainline)
Virtualization QEMU_KVM
Application Minecraft
Module MinecraftModule
Running in Container No
Current State Failed

Problem Description


The server crashed, not sure why. No one changed any settings we were just all playing and now when I try to start up the application I get this error:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread “main” java.lang.UnsupportedClassVersionError: net/minecraft/bundler/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0

I’ve double checked, and Java 8 is still set (which is the version we need for 1.7.10 modded minecraft)

Reproduction Steps

  • Check Java 8 is set
  • Update and start application
  • JNI error

The error is explaining the issue. The file version is 61, but Java 8 only supports up to file version 52. You need to install Java 17 at minimum to handle files compiled with file version 61.

But that doesn’t work with the version of Minecraft we are playing on, which only works with Java 8.

It runs with Java 17 fine after the crash, but then the server is no longer modded 1.7.10 Minecraft, it’s now vanilla 1.20.2 Minecraft.

I’m not familiar with the entire Java version of Minecraft, just know Java programming in general. The Java deployments are backwards compatible, so Java17 can run older versions of minecraft. As for the version changing, there must be a setting that needs to be changed to force the older version to run…Not sure on that one.

I work in Java, so I understand what’s going on, I just don’t know how to fix it in this system.

Somehow the file has been compiled since/during the crash with a newer version. So I need to recompile the file with the correct version of Java but I don’t know how to do that via AMP or how to find the file.

It could be AMP updated your minecraft version after the crash. I do know under the instance config server settings, there is a drop down for release stream which gives you the option to select specific version. But havent used that before, so not sure where you define that specific version. Maybe someone else can chime in on that one.

Did you use AMP’a built in FTB installer? If so you also need to set the proper version info after installing the pack, since FTB doesn’t provide version info via their API.

May also be a case of forgetting to hit “download/update”, or the Jar may not be set to “Autoselect”

I did use the FTB installer. How do I set the proper version?

I’ve hit download/update a bunch while trying to troubleshoot, and I make sure I stop, update, and restart the server during any changes. The jar is also set to autoselect.

The server was working fine a few hours ago (for over 24 hours), and then crashed without any config changes.

Double check that the everything lines up with the 3rd guide in here:

If that still doesn’t do anything, send over a screenshot of your server settings and toss over whatever shows up in the console

I switched to use the Forge version as suggested in the guide, and the server is booting up now, but is crashing during loadup.

I just troubleshoot the issue and many people said about updating MFR config about a vanilla milk override, but I’m still getting the same issue.


at net.minecraft.nbt.NBTTagCompound.func_152449_a( ~[dh.class:?]
at net.minecraft.nbt.NBTTagCompound.func_152446_a( ~[dh.class:?]
at net.minecraft.nbt.NBTTagCompound.func_152449_a( ~[dh.class:?]
at net.minecraft.nbt.NBTTagCompound.func_152446_a( ~[dh.class:?]
at net.minecraft.nbt.CompressedStreamTools.func_152455_a( ~[du.class:?]
at net.minecraft.nbt.CompressedStreamTools.func_152456_a( ~[du.class:?]
at net.minecraft.nbt.CompressedStreamTools.func_74794_a( ~[du.class:?]
at ~[aqk.class:?]
at net.minecraftforge.common.chunkio.ChunkIOProvider.callStage1( ~[ChunkIOProvider.class:?]
at net.minecraftforge.common.chunkio.ChunkIOProvider.callStage1( ~[ChunkIOProvider.class:?]
at net.minecraftforge.common.util.AsynchronousExecutor.skipQueue( ~[AsynchronousExecutor.class:?]
at net.minecraftforge.common.util.AsynchronousExecutor.getSkipQueue( ~[AsynchronousExecutor.class:?]
at net.minecraftforge.common.chunkio.ChunkIOExecutor.syncChunkLoad( ~[ChunkIOExecutor.class:?]
at ~[ms.class:?]
at ~[ms.class:?]
at net.minecraft.server.MinecraftServer.func_71222_d( ~[MinecraftServer.class:?]
at net.minecraft.server.MinecraftServer.func_71247_a( ~[MinecraftServer.class:?]
at net.minecraft.server.dedicated.DedicatedServer.func_71197_b( ~[lt.class:?]
at [MinecraftServer.class:?]
at net.minecraft.server.MinecraftServer$ [li.class:?]

In the logs:

EnderIO: Found the following problem(s) with your installation:
                  * The RF API that is being used (1.7.10R1.0.2 from <unknown>) differes from that that is reported as being loaded (1.7.10R1.0.3 from SolarExpansion-Basic-1.6a.jar).
                    It is a supported version, but that difference may lead to problems.
                 This may have caused the error. Try reproducing the crash WITHOUT this/these mod(s) before reporting it.

Looking around a bit, it looks like there may be some missing/corrupted NBT metadata while loading the world. Saw one GitHub issue that lead back to ProjectE and another post that was related to Pixelmon, so not too concrete as to what the cause might be.
One post said you might be able to use an NBT editor to fix things, but I’m not entirely sure what you’d need to fix.
Would you happen to have any backups of the server handy?

Yeah I think you might be right.

I went to a backup at 5am this morning and it worked fine. I then replaced the world folder and it’s crashing again, so must be something weird with the mods.

I guess my best bet is to start a new instance and try to manually install the modpack?

Could see about downloading the backup from 5am, then restore that in a new instance, or you could take a backup to save the current messed up state of things, delete all the folders, then try and restore from the backup.
Alternatively you could spin up another instance, install the FTB pack, swap the server type to Forge, then see about importing just the world from the backup.
The last method there would be easiest/cleanest imo. Then you could copy it all back to the original one if you have a bunch of stuff set up in the scheduler.
Gotta love modded Minecraft and all it’s quirks lol.

When you say install the FTB pack, did you mean manually?

I followed your last method and the server crashed at the same point as the original issue :confused:

That’s really weird, I’d say try and install the server pack on your PC then upload that into AMP yeah.
I’m currently running FTB Infinity Evolved 1.7.10 and haven’t run into any weird issues, could be something weird with the pack you’re using, old modded MC likes to pull some funky stuff sometimes

I’m also trying to run FTB Infinity Evolved 1.7.0, I’ll give it a go with the local install.

I’m going to have to do it on the server though right? I’m on a Windows so if I install locally it’ll be for windows?

You’ll want to install it in a local folder then upload it over SFTP. Manually messing with files in the windows file explorer will mess up file perms

The server is linux/debian sorry I meant to say. Will the server files be the same?

They should be yeah, only difference with their install binaries is just the OS that they run on

Well the server was running fine after installing the files manually on the server, so this thread I think is solved.

Thanks for all your help, really appreciate it.

Now the server keeps lagging and AMP is unable to access the backend lol. Do I need to make a new thread?