In this post, I want to elaborate on one more common mistake. Well, mistake may be too strong word. It's about a default option when you run a Java JDK installer (see the other post for more on JDK vs JRE options).
In short, I make the case here for why you should NOT let the JDK installer implement its "public jre" option.
As I concluded in that earlier blog post, do beware that when you run the Java JDK installer, it will have a few options, one of which is the "public jre". You should generally choose NOT to install that, both for security reasons, AND to prevent Java from later prompting you or someone else to let it update itself, which then could break CF. One other reason is in case there may already be another JRE already installed and being used (by default) by other applications. Let me explain all these.
Testing for whether this is already another public JRE
First, let's just do a quick check.
If you go to the command prompt on your machine, and run the command "java" (no arguments, just the word java by itself), what do you get? If it's an error that the command can't be found, then I'd argue that's a good thing. It means that there is no "public JRE" on your machine...no version of Java that's been installed in such a way that it can be used by any program on the machine. That's what "public" means here (not that it's public to anyone OFF your server).
Why is it better not to have a public JRE?
So why is it better to NOT allow java to be run on the machine this way? For security reasons, primarily. Because then if somehow some bad guy DOES get onto your machine, or more likely just leverages some vulnerability and gets some sort of code ONTO the machine, they would be able to leverage Java without needing to know where it may be. It's "public".
What if you DO have a public JRE?
So what if you DO find that java does respond at the command prompt (in a directory where this is no java.exe, to be clear), showing the options for launching java programs? Well, that means you or someone DID let the Java installer enable that.
Or perhaps someone installed ANOTHER JVM on the machine, which enabled that public JRE.
And here's something to consider: maybe you should NOT be changing THAT public JRE, or you may break that other software relying on it. Perhaps there is some older software that relies on an older JVM version (like Java 7) of the public JRE you do have.
Note that you can do a java -version command to see the version that java command is running.
You can also find out in what location the OS is finding that Java command, using the "where java" command in Windows, or "whereis java" in Linux. If it's not the location that CF is pointing to (as can be viewed in the "settings summary" or "system information" pages of the CF Admin), then it's one that maybe exists for some other reason.
How does a public JRE get installed?
If it's that you or someone did use a java JRE installer (as opposed to a JDK installer, as discussed the second "problem" of the other blog post), then just note that this is what a "JRE installer" does: implement a public JRE, and you can't control that.
But if you download and run a JDK installer instead (as recommended in my other blog post), then while it DOES implement a public JRE by default, you can choose to NOT let it do it, and I'd argue you should.
It's the 3rd option on the 2nd screen of the installer (along with options for implementing the JDK developer tools and getting java source code). Pick the "public jre" option and choose the drop-down value, "this feature will not be available" (you can do that for the source code, too.)
Now the JDK will be installed, but NOT as a public JRE. Instead, you could proceed to point CF to this JDK as discussed in more detail in the other blog post. (Technically, as I discuss there, you point CF to the JDK's JRE folder. Yep, the JDK DOES have a JRE...it's now just not going to be "public". It will only be known to apps that you POINT TO it.)
Another reason to avoid the "Public JRE": auto-updating of Java
This is one of those two-edged sword problems. Let me explain.
1) If you install the JDK (and have CF pointing to it), but you leave ON the "public JRE" option, then this will also cause Java by default to track a fixed "expiration date" for that specific JRE. And when that date passes, you or someone on the box will get a prompt to update it.
And if you proceed to run the update, guess what? It will put in the new version (yay), but it will also attempt to uninstall the old version (boo). OK, let me clarify: if this was a JRE installer, implemented intentionally (for some other purpose), this auto-updating of Java would be fine, even desirable.
2) But when you have installed a JDK for CF to use, and left its "public jre" option enabled, then when this auto-update mechanism tries to run, it likely won't be able to do its job--because CF is running and pointing to it, and so has locks on some of the files in the JVM directory. So the uninstaller will dutifully delete what it can, leaving the few remaining ones in place.
3) And then guess what? the next time you try to restart CF (whether it's minutes, hours, days, or weeks later), suddenly "boom", CF won't start. Because most of the JVM files it needs won't be there anymore. (It had loaded classes and jars into memory when CF started previously, before the uninstall, but they're not there now.)
And you'll be pulling your hair out trying to figure out why.
4) Worse, it may be that the only reason you just restarted CF (perhaps in a long time) is because you just applied a CF update. And when CF doesn't start, what will you blame? the CF update. And perhaps you'll grumble about Adobe making such crap software, and so on.
But what really happened is that you or someone let the JVM update itself, and now CF can't find the JVM it's pointing to.
5) So if you choose to NOT enable the "public JRE" option of the JDK installer, you fix both problems discussed here: you don't enable (or change) any java command that can be run at the command line (which could be a security risk), and you don't cause Java to update itself (which could break CF when it next restarts).
6) Of course, this DOES mean that it's on YOU to then stay aware of when there are new JVM updates, and to implement them when you're ready, and to change CF to point to that new JVM location yourself. (If you forget that last point, then again CF will not start. See the 6th "problem" in the other blog post.)
So should you maybe just run a JRE installer rather than a JDK?
Given that last point about the auto-update mechanism and the changing of folder names "confusing" CF, one might make the point that instead of getting and running a JDK installer, they should just get and install a JRE installer (there is also a "server JRE" installer option offered by Oracle. See the other post for a link to the installer locations, etc.)
I think the motivation for that question may come from the fact that there was a time when JRE installers just implemented themselves in a Java directory which had no version number in their name (like C:\Java, on Windows). And so an argument might be made that then you could point CF to this one java folder, whose name should not change due to various updates within a major java version.
But I've noticed that with recent java versions (7 and 8), even the *JRE* installer (as I've used it for other reasons) has installed itself in a numbered foldername, such as C:\Program Files\Java\jre1.8.0_102 (in Windows). So no, that does not seem to "solve the problems" just discussed. (Whether one can use the JRE installer at all with CF is another question that I discuss a bit in the second issue of the other blog post.)
So in conclusion, the above reasons (primarily security and preventing auto-updates of Java) are why I would argue one should NOT implement the "public JRE" option of the java JDK installer.
Hope that's helpful, and I look forward to comments.
For more content like this:
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, I can help via my consulting services
- See that for more on how I can help a) over the web, safely and securely, b) usually very quickly, c) teaching you as we go, and d) with satisfaction guaranteed