Trying to install Minecraft server - can't install the correct JAVA version

Question

My goal is to install a Minecraft server on my Raspberry Pi 4B with 8GB RAM.

I mainly followed this guide which includes a script to install all of the components quickly.

The main commands are:

wget --no-check-certificate --content-disposition https://github.com/ThamesDev/rpi-mc-server/releases/download/1.1.0/rpi-mc-server.tar.gz
tar -xvzf rpi-mc-server.tar.gz

And then the script does the following:

sudo mv start-server /usr/bin/start-server
cd $HOME
mkdir MinecraftServer
cd MinecraftServer/
wget https://launcher.mojang.com/v1/objects/0a269b5f2c5b93b1712d0f5dc43b6182b9ab254e/server.jar
wget https://github.com/AdoptOpenJDK/openjdk16-binaries/releases/download/jdk-16.0.1%2B9/OpenJDK16U-jre_arm_linux_hotspot_16.0.1_9.tar.gz
tar -xvzf OpenJDK16U-jre_arm_linux_hotspot_16.0.1_9.tar.gz
sudo ln -s $HOME/MinecraftServer/jdk-16.0.1+9-jre/bin/java /usr/bin/java

I am quite new to the command line but I am tech-savvy in general. As far as I comprehend it, all the files are where they are supposed to be. This means:

• the start-server file has been moved to /usr/bin
• the MinecraftServer folder exists, in it is the server.jar file and and the .tar.gz file which has been extracted ("tared") to a jdk... file
• the last command (sudo ln...) seems to have worked too, since when now redoing that line I get "the symbolic link could not be created: the file already exists"

What I don't understand is when I try to launch the server, which is done by either

start-server [mb argument for RAM]

or (which is just the command that the start-server script executes)

java -Xmx[mb argument min] -Xms[mb argument max] -jar server.jar nogui

I get the following error:

Beim Laden der Klasse net.minecraft.server.Main ist ein LinkageError aufgetreten
java.lang.UnsupportedClassVersionError: net/minecraft/server/Main has been compiled by a more recent version of the Java Runtime (class file version 60.0), this version of the Java Runtime only recognizes class file versions up to 55.0

This tells me that something with the JAVA version is wrong. Indeed, when asking "java -version", I get Java 11. However, I also can't switch version, since sudo update-alternatives --config java gives an error, saying: There is only one alternative in the link-group (provided by /usr/bin/java): /usr/lib/jvm/java-11-openjdk-armhf/bin/java. Nothing to configure

So my question is: How can I install the newest JAVA version 16 on my Raspberry with Raspbian to avoid this error?

---

I am aware of another thread about this on this SE. However, as far as I understand it, the script already uses this version of Java from that exact website.

Other guides I tried following but didn't help:

• https://linuxhint.com/install-oracle-java-jdk-16-raspberry-pi/
• https://www.reddit.com/r/raspberry_pi/comments/nxdva3/install_java_16_on_raspberry_pi/

Since a couple other guides mention changing the $PATH variable I ended up now with quite a mess in there I think, but this is a separate question if this does not interfere with my aim of installing a minecraft server:

$/usr/bin/jdk-16.0.2+7/bin:$/MinecraftServer/jdk-16.0.2+7/bin:$/home/pi/MinecraftServer/jdk-16.0.2+7/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

Answer 1

I also can't switch version, since sudo update-alternatives --config java gives an error, saying: There is only one alternative in the link-group...

You need to inform the alternatives system of the new installation by using update-alternatives --install ... appropriately first (see man update-alternatives).

With regard to your initial/other problem involving $PATH:

other guides mention changing the $PATH variable I ended up now with quite a mess in there I think

Yes, if this is the output from echo $PATH, then you messed up a bit which would explain why trying to use the new installation failed; I've broken the line up for illustration:

$/usr/bin/jdk-16.0.2+7/bin
:$/MinecraftServer/jdk-16.0.2+7/bin
:$/home/pi/MinecraftServer/jdk-16.0.2+7/bin
:/usr/local/sbin:/usr/local/bin
:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games

If you do any programming, this is the shell's representation of an array (if you don't, an array is an ordered list of things which can be referred to using an index). Each entry is separated by a colon. Notice the first three entries are prefixed with a $. Exactly how you did that is possibly because of a misunderstanding of something (that might be counter-intuitive if you are used to more normative modern languages): When you want to substitute the name of a shell variable with its value, the name is prefixed with a $, hence echo $PATH does not literally print $PATH but the value of the variable with that name.

You can use such a substitution in another variable assignment, and you can also use a literal $ in same if it is prefixed ("escaped") or quoted properly. Eg:

> mypath=$PATH; echo $mypath
/usr/sbin:/usr/bin:/sbin:/bin
> mystring=\$PATH; echo $mystring
$PATH

See the difference? In the first case, you have a copy of the existing $PATH (the actual value is just an example). In the second you have the literal string, $PATH (and notice also how the literal "$" requires a backslash escape, \$).

Hopefully you've used the command line enough that the format of unix/linux paths is familiar, including the fact that an absolute path begins with a / (and just / is the toplevel directory). Conventionally, all entries in $PATH are absolute, but there is no rule about this, and there are very few restrictions on what a legal file/directory name is, so the shell will rarely if ever tell you your $PATH has problems, including non-existent elements -- since those might only be temporarily missing due to the status of mounts, etc. If there's something which doesn't currently correlate to a real location it is just ignored.

Further, $ is a completely valid file/directory name (although, like *, it is probably a very poor choice if a standard shell is going to be used on it). So in theory, $/usr/bin/jdk-16.0.2+7/bin is a viable path element if you happen to apply it in a directory which contains a subdirectory named $ with all that other stuff inside it.

If such doesn't exist, which it wouldn't unless you'd done more strange stuff already, it will just be ignored. Hence, the only viable elements in the path shown at top here would be the bits in the last two lines, which are pretty standard and obviously don't include anything in /usr/bin/jdk-16/bin (since path elements don't include subdirectories thereof).

So, the changes I made to $PATH are useless, but also do no harm, correct?

Well, not if you discount the frustration it may have caused you. But be careful with it. "Incorrect" (or maliciously contrived) path elements can have nasty consequences if they do happen to exist and contain things named eg., echo or ls that delete everything in the current directory, etc.