Edit Simon: This thread arose from NeoLemmix, SuperLemmini and Lix, Feature Comparison by WillLem.
The Java Runtime is beh as a dependency, can't just ship the game binary and DLLs, always have to tell people to install Java.
This is another topic I could go on a very long rant about. As a user, I hate Java (I've also heard things about the language itself, but I can't really speak for that because the fact that any Java code I'd write would have to be run on the JRE is honestly kind of a dealbreaker for me). I hate Java so much. And it's not just the fact that you have to download a runtime environment that makes this annoying, because you need to download the Python interpreter to run Python code, and that language isn't nearly as irritating about it.
For what reason? This strikes me very much as a "hating for the sake of it" kind of thing. Java is fine: the vast majority of applications require you to install something, Java RE is something you only install once and then you can run any Java app natively. And, it's multi-platform compatible. I'd say that's relatively convenient, as computer-stuff goes.
What I will say is that Java runs very slowly on my Mac, for some reason, and that is a bit disappointing, but not annoying. It's a 2012 MBP, so it's probably just not been able to keep up with the updates.
Well, since you asked:
Dullstar's Java RantA lot of this is based on some... adventures... with modded Minecraft, so I suppose it's possible that I'm directing blame to the wrong place, but...
The JRE has two major issues (or at least, had - I've had the updater silenced for quite some time since I only use it for Minecraft now). First, it has my least favorite type of updater: the one that simply tells you that an update exists, but you have to do all the work yourself. This would always lead to a lot of fun adventures back in the day related to making sure Minecraft had all the memory it needed: the downloads page would (I seriously hope they've fixed this by now) always want to take you to the 32 bit version, so then you'd have to track down the 64 bit version instead, which of course was not on the same page because of course it wasn't. Okay, so you found the 64 bit version, let's try to install it, aaaaand oh it wants to install some other junk we don't want. Untick those boxes for like some McAffee trial or Ask toolbar or whatever it was they were peddling... okay, finally, it's installed! A few days later - there's a Java update! Click here to start updating. You wanted the 32 bit version, right? No? Well, then, find the 64 bit version again... download... start the installer... untick the boxes...
For comparison, the Python interpreter:
Go to the website, click downloads, it's easy to find the other builds if it doesn't default to the one you wanted, run the installer, and you're done. No wild goose chase to track down the 64 bit version, no extra junk to opt-out of during the installation. You only need to do a bit of manual work with the installation if you want to change some of the settings, but the defaults are all reasonable.
The second issue is that the JRE is
terrible at memory management. For many applications, this doesn't matter because the memory usage never gets that high, but that's not the case for every application out there. Instead, you must tell it how much memory it should allocate ahead of time. Now sure, there's defaults, but they're not suitable for all applications, and when you have to mess with them, that's when things get pretty nasty. Don't allocate enough, and the program will keep pausing to run the garbage collector. You can give it a bit more breathing room by expanding the amount of memory it has to work with, but be careful if you're running other applications in the background! Allocate too much and the JRE will crash when it needs to use that memory - it can't cleanly handle the system running out of memory. Granted, many applications can't - but Java is garbage collected, so if you run out of memory, there
is something it should be able to do: run the garbage collector to free all the junk. So if you've got an application that requires a lot of memory, such as a modded version of Minecraft, you'd better make sure there's no memory hogs running in the background like web browsers can sometimes. Being able to limit the memory usage of an application that's holding onto unneeded stuff in memory simply for performance isn't a terrible idea - that'd be great for making my web browser play nicer with other applications since it likes to hold some stuff in memory to speed up loads and overtime can lead to the browser consuming like half of the available memory even though it doesn't actually need that memory to function. But if you're running something like a game, you probably want the computer to give the game everything it's got (well, if it would benefit from it anyway), and this is where the weaknesses of Java's memory management show through the most. That's because the maximum memory allocation size isn't just a cap: it's also a promise to the JRE that it will receive up to that much memory if it requests it. This means I can't give it free reign to use as much memory as it needs, because I have to choose a maximum memory allocation such that I expect it to
always be available. And of course it doesn't allocate this right away (I mean, it really shouldn't, but if it's going to behave the way it does at least this would make it a start-up error instead of a runtime error) - it waits until the application needs that memory, but it also adjusts the behavior of the garbage collection
based on this, so you'll have a lot of situations where it decides to allocate more memory instead of running the garbage collector. And then if that memory isn't available, the program crashes! Frustrating!