Heads up on Mix-Match JAVA Vers on hosts

  • 74 Views
  • Last Post 20 September 2021
  • Topic Is Solved
packetnarc posted this 20 September 2021

To anyone that has had a bit of a struggle with the wrong JAVA versions for their needs; here's a tip. (this is especially important if you have been running 1.7, 1.12, 1.16 servers, etc. And are now dabbling in 1.17.x which is on a different JAVA version.)

Regardless of whether you're running AMP over Windows or Linux or on a single box or Controller / Distributed "AMP Doesn't know which JAVA version goes with which Server version". (for Minecraft, for instance). So when you go into your instance and select "1.17.1" as an example; AMP is NOT going to remind you "Hey, all your other versions use JRE 1.8 and now I require JAVA 16"... What it's going to do is let you change the MC Version, and attempt to start it and fail.

(I haven't spent much time with AMP but I presume there's a way to set defaults for certain types of instances.)

ALSO, let me save you some googling around: IF you go into the "JAVA and Memory" tab of the instance config and you go to the JAVA version and don't see the one you want it is because AMP hasn't detected that you have it installed on your system. In the case of an AMP Server where you're deploying instances LOCALLY, this means you need to put the right version(s) of JAVA on the same system AMP is running on so that it can detect that version, and add it to the drop down box for you. (regardless of whether this is Linux, Windows, etc. AMP Apparently scans the common JAVAPATHs for JRE / JDK instances and adds them to the dropdown. But only when AMP starts up.)

Which means, anytime you add a new JAVA version to your system or CHANGE your default JAVA (by either manipulating the PATH Command yourself, or by letting a JAVA installer do it for you) you have now pretty much guaranteed AMP won't know about that change; until such time as you RESTART the AMP process. (again, whether you're on Linux or Windows doesn't matter)

I haven't yet experimented with how this works on a distributed setup where you just have a standalone controller pushing out to specific "nodes" for Minecraft for instance. It sure would be clever if you could look at your "targets" for instance and check their compatibility for certain server versions based on the targets installed JAVA versions.

If you have a single JAVA instance and the path correctly set (e.g. you can run JAVA by just typing "JAVA" at a command prompt) you will probably have no issues running Minecraft servers from 1.12 --> 1.16.5. All of which use JAVA 8 (doesn't matter if you're using Oracle, OpenJRE / etc.)

If you want to know which JAVA version your system is using for default, just go to the CLI and type "java -version or java --version depending on the platform you're on." And it will probably say something like:

//--\ java version "1.8.0271" Java(TM) SE Runtime Environment (build 1.8.0271-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.271-b09, mixed mode) \--//

REMEMBER though; On Linux especially; you can have several different versions of JAVA installed which happily coexist. They don't interfere with each other. Usually; when you manually run multiple MC Servers on a host, you can call the entire path for the required JAVA version when you launch the server. The same applies to Windows. Although, it can be much more difficult because many times windows will insert the JAVA_PATH into the installer when you install a JAVA application and it presumes the default is the correct version. So, if you have a buggy version of JAVA or an app, it can be a bit of an exercise to manually launch that offending App with an alternative JAVA version. But, that's out of scope for this already long post.

In any case, in the event you need to support multiple versions of JAVA on a Linux host its pretty trivial because we're launching processes or dedicated servers from either SystemD or a shell script. Both of which afford us the ability to SPECIFY which binary should be used to launch any app. You have that same ability to "specify" within AMP but it's not AutoMagical.

So why did I take the time to point all this out ? Well for one, there are a lot of you that haven't spent close to 30 years doing this crap so I figure I'd take the "teach a man to fish" path and help you poor suckers out. Also, hosting game servers on your own is a fun and interesting hobby; and it can be intimidating to get things to work if you don't have a lot of stick time on these systems and tools.

It's not rocket surgery but the manner and mechanism for launching a JAVA Virtual Machine (JVM) are many and varied and depend heavily on the platform you're on.

The AMP tool is an awesome alternative to trying to build out a Ptero setup or something but it doesn't currently have the sophistication to detect or alert you when you have mismatched the required version of the JRE with the corresponding JAR. So, AMP counts on you to know how the path and defaults work, and how to properly keep your system current and properly configured to support the tools.

There isn't a lot of verbose doco on this topic either; so hopefully if someone comes along and is struggling to get a mixed environment working this will save them some time.

Mike posted this 20 September 2021

There is actually a plan for AMP to be able to 'catch' the situation where the wrong Java version is used - but only once it's already tried to start the server. It's not possible to know ahead of time what Java version any given Jar file needs in any reasonable way.

Indeed, it does rely on you checking the documentation for the server you're using to see which Java version it's expecting.

  • Liked by
  • packetnarc
Close