CF911: 'Help! I've updated the JVM which ColdFusion uses, and now it won't start!'

Note: This blog post is from 2014. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Has this happened to you? You wanted to update the JVM which CF uses to use a new version...

• so you found some resource on the web showing how to update, and it seemed simple enough
• and then you tried restarting CF and wham, it won't start, or the admin won't open, or code starts failing
• and maybe it's that things didn't fail immediately, but within hours or days folks report things breaking since you made the change
• and now you're stuck wondering, "what happened? and how am I supposed to fix this?"

It's a tough position to be in, and tragic of course if CF won't start. But no, you do NOT need to reinstall CF!

Often it's just one thing you did by mistake, though there are indeed several possible reasons why your attempt to update CF's JVM can fail or lead to unexpected problems. And as you google about, you may find all kinds of helpful but often misinformed or spartan suggestions that may or may not help much.

So I offer here over a dozen of things you can and should consider/look at, some of which you may quickly recover from or be able to undo (depends on what you did). And all this applies to Lucee, Railo, and BlueDragon as well, though folder locations will differ.

If you're facing this bind right now, you can skip over the following to the the section, "Seeing better error info, when the CF service won't start", and then the section after that "So what went wrong?", where I present each likely problem and solution.

In brief, here are the things you may have done wrong. See below for solutions or recommendations:

1. You may have gotten the wrong bit-level of Java for your bit-level of CF
2. You may have gotten the wrong JVM for your OS
3. You may have tried to use a JVM not supported by the version of CF you're running
4. You may have gotten the wrong kind of Java installer
   
   And while those above have to do with getting the RIGHT JVM, sometimes the issues arise with how you setup to point to that JVM:
   
   
5. You may have pointed CF to the wrong JVM location
6. You may have forgotten to change the path's directory separator slashes on Windows
7. You may have made one of these mistakes, and now CF won't start, so you can't see the CF Admin to correct your mistake
8. You may have updated the JVM config for the cfusion instance, but not your other instances
9. You may have told the Java installer to install itself WITHIN (or extracted the zip) the CF JRE directory. I will argue that you should be very careful about doing that.
   
   Still other issues involves steps you must take AFTER updating the JVM, even if you do the change and point to the JVM "correctly" otherwise, especially when implementing a new major JVM version (like 6 to 7, 7 to 8, 8 to 11 and so on):
   
   
10. You may need to copy a needed MSVCR100.dll file from one of the JVM's folders into one of CF's
11. You may need to copy the tools.jar from the JVM's lib to CF's when updating older CF
12. You may need to delete the cfclasses folder, holding files created by CF when it compiled CFML into java and saved
13. You may need to delete the java "stubs" where CF had compiled code for web service calls
14. You may need to delete the rest-skeletons and cfc-skeletons folders where CF had compiled other files
15. You may need to import SSL certificates into the new JVM--but beware, perhaps you don't NEED to!
16. You may need to carry forward files placed into the bin folder of the JVM that CF was previously using
17. You may want to consider also editing the Solr (or technically, the "jetty") jvm config file, so that it points to the new JVM

While I'm at it, I also cover:

• Beware that CF also can't even STOP (let alone START) if you make some mistakes with the JVM configuration
• How to go about updating the JVM
• What JVM version(s) are supported by what versions of CF
• Beware leaving the Java installer to choose the "public jre" option

So this really became quite a compendium of resources on changing the JVM CF uses, but again the focus is on why CF may not start if you make certain very common mistakes.

As for why I'm writing this post, someone today made this very plea for help in a comment on the Adobe blog, and I started to write a reply there. It became too lengthy for a comment, so I am posting the answer here and pointing to it there. And as often happens, I have then elaborated still further beyond what I was going to write in the comment (and still more since first posting the entry here), all just trying to help those looking for answers. (This is one of those topics where most explanations on the web are just not complete enough to avoid falling into trouble.)

Some context: it all seemed so simple

So you had some reason to want to update the JVM in CF:

• maybe you discover for the first time that the JVM which CF comes with is rather old (they had to pick one to include, when they first built that version of CF, and it isn't long--perhaps only days before or after a CF release--that an important new JVM update comes out)
• Maybe you're finding that calls to https pages are failing from within cfhttp, cfinvoke, cfobject/createobject, and you heard that it's that the site you're calling has updated (or removed) levels of SSL/TLS supported, and that you should update your CF to a later JVM that support such later versions of SSL/TLS
• Or perhaps you hear that CF can now support a new JVM, like how CF11 update 3 and CF10 update 14 each added support for Java 8, and you want to make that move.

So you may want to update CF to use a later jvm version, whether from one point release to another, or from one major release to another.

So you google around, find some instructions, and it seems simple enough. (And indeed, if done correctly, it's literally a 5 minute job which is easily reversed if needed.)

So you take a deep breath, and do the update as seems right from what you've read, and you restart CF, and...oh $#!+, it won't come up. (Or maybe it won't even go down. More on that in a moment.)

Now you panic, and you re-read the resource you read, only to find that it tells you only how to make CF use the new update. It doesn't tell you how to recover if things go wrong. And it probably didn't warn you of what to watch out for.

So you google around some more to try to find out what went wrong, and you find lots of people offering lots of suggestions, only they may or may not apply to the particular approach you used to make the update (and you may have made a grave mistake, like telling the Java installer to put itself INTO the CF JRE directory--something to be very careful about, as that would not remove what was ALREADY in there from the old JVM Adobe provided there).

And now you curse that you ever started...

But your clients or bosses are breathing down your neck because CF has been down for 3 hours...

And you were just trying to do the right thing...

(And now's probably not a good time for me to comment about how it would have been wise, if doing such a JVM update for the first time, to try it on a local development environment, or a test machine, rather than a production machine. And of course to take a backup or vm snapshot.

And if you're reading to this point and wonder "so I was wondering first just how do I update my JVM?", that's a different matter. I'll point out some resources at the end, in the section, "How to go about updating the JVM". While some of them do a good job of pointing out gotchas, I've not seen in one place anywhere all the following observations of problems and solutions. Anyway, I'm speaking in this entry mainly to those who already did do the upgrade, and are now finding that CF won't come up or work right.)

Seeing better error info, when the CF service won't start

[Update: This section here is an addition since the original post, thanks to a heads-up comment by Jeffry Houser. It's information I do indeed suggest to people and use frequently when tackling JVM update problems, but when I first wrote this post in Dec 2014 I was focused more on what the problems were and how to solve them, just like I didn't focus on such things as best practices on how to DO the JVM update, pointing elsewhere for that instead.]

Before tackling the many different things that MAY have gone wrong with your JVM update, let's start with a more basic point: if you are running CF as a service (in Windows or Linux or MacOS) and you find that starting CF simply fails, you will NOT likely find any useful information in the CF logs, nor in the Windows event logs or Linux journal/logs. If the service doesn't start, because of JVM issues, that won't be written to the CF logs, because those are written ONCE the service starts.

Instead, what you will want to do as a first diagnostic step is to try starting CF from the command line. You can do that easily. Go to the bin folder for the CF instance in question, found in the root of your CF folder.

If you only have one instance, the CF subfolder is cfusion/bin. If you have an instance named myinstance, it's myinstance/bin. And in there, will be a cfstart.bat (for Windows) or cfstart.sh (for Linux).

In Windows, open the command prompt as admin, cd to that bin folder, and run

In Linux, cd to that folder, then use sudo or su root, and then run

(While the cfstart.sh for Linux does prompt you if you don't run as root, the cfstart.bat on Windows does not "require" you to run as admin". But it's important to run "as admin" or "as root" because someone may have configured your CF service to run as a user with limited permissions, and they may have configured the CF folders to be accessible to THAT user. But the user YOU are running as may not have those needed permissions. Running "as admin" solves that. Again, we're just running this at the command line for diagnostic purposes.)

If there is a problem regarding the JVM that CF is using, an error will be shown on the command line. It may help you see that there's a problem with the path, or a problem with the bit-level of the JVM you are using, or with some related dll file that is missing.

See the next section for the many different things that can go amiss, and how to solve them.

Beware running cfstart from powershell

[Update: as for running CF from the command line, do note that if you may run the cfstart from powershell instead, that may not pop up the error discussed below about a missing dll. You only see that if you run cfstart from CMD. And to avoid possible permissions issues, do open that CMD "as administrator", as discussed above.]

So what went wrong?

So you updated CF to use a new JVM, and now CF won't start? What's the problem? Where did you make a mistake? Now, I don't know what particular approach you took (there are various possibilities), but there are several very common mistakes, and some are easy to recover from.

The good news is that I have here some clear suggestions, and in most cases your solution to this problem is only minutes away. I've been helping people either update their JVM, or helping recover from such mistakes, for years in my consulting practice.

So what might have gone wrong?

• Problem: You may have gotten a JVM at the wrong bit-level for the version of CF you're running.

  If you're running a 64-bit version of CF, you need a 64-bit JVM. (And even if you're running on a 64-bit machine, if you're running a 32-bit version of CF, you need then a 32-bit JVM!). It would be easy to download the wrong one.

  First, you may not realize you are getting the "wrong" one: the Java download pages use some rather old nomenclature, where "i586" indication for Windows downloads (as in jdk-7u71-windows-i586.exe file, for instance) means a 32-bit version of the JVM.

  Second, you may not KNOW what bit-level CF was. (Actually, I will add as an update that since CF2018, Adobe no longer supports 32-bit JVM's, so if you are on CF2018 or higher, you MUST use a 64-bit JVM.)

  If you can get into your CF Admin, see the "settings summary", look for the "jvm details", and specifically the "Java VM Name" (then skip the next paragraph).

  If instead your CF admin won't come up, you can't use that to find out, but here's one way to know: go to the command line, cd to the bin folder within CF's JRE folder (by default [coldfusion]/jre/bin for CF9 and later, or [coldfusion]/runtime/jre/bin for CF9 and earlier), and run the "java -version" command there.

  Either of those (the admin or the cmd line) will report the version of THAT jvm (that came with CF originally), including a phrase such as "Java HotSpot(TM) 64-Bit Server VM". That says it's 64-bit. If it says just "Java HotSpot(TM) Server VM", then it's 32-bit.

  Whichever it is, THAT is the bit-level that your CF expects--and it will ONLY support that.

  Solution: Again just install the right one. If you run the java installer, it will each install version into its own directory by default and they can co-exist on a given machine. Once things are working, you could uninstall the "wrong" JVM, if you installed it and know that you don't otherwise need it for any other apps on the machine.

• Problem: You may have downloaded the wrong JVM for your OS.

  This is a little harder to do by mistake, but double-check what file you got against the list shown, such as that for JDK 7.

  Solution: Again, get the right one and try again.

• Problem: You may be trying to use a JVM not supported by the version of CF you're running.

  Solution: Java 8 and 7 are only supported in certain CF version/update combinations. For more, see the discussion below, So what JVM is supported by what versions of CF?

  Assuming you didn't make this mistake, and you DID install the JVM into its own location, then you may have read how you're then to tell CF where that JVM is installed. But that's where you can make another common mistake. Before that, let me make one more last observation of a possible mistake in WHICH JVM you get.

• Problem: You may have gotten the wrong kind of Java installer

  This is not as common a problem as before, when many were running CF on 32-bit Windows.

  First, let's note that there are 3 kinds of JVM downloads one can get from Oracle: the JRE (Java Runtime Environment), the JDK (Java Development Kit, which includes the JRE), and the Server JRE (a trimmed down JRE, without an installer, means for some server deployments of Java).

  They're not all the same, but more important not all will work with all implementations of CF. For instance, you may download and install a Java "JRE" where you may really need a "JDK". The Oracle site (and google) may guide you to getting a JRE, but I (and others) will propose that you generally want to instead get a JDK.

  (Now, some will say they do get by ok with a JRE on anything but 32-bit Windows, or that the "Server JRE" will work though I've seen problems with that, so I just recommend a JDK to be safe as a matter of course. It's never let me down).

  Solution: Here's some good news if you got a JRE and need a JDK: you can simply install a JDK even if you've first installed a JRE, no problem. They install to entirely different directories. Just do that install, and note the location of the JDK (technically, the JRE within the JK) and then change CF to point to that, as discussed next.

The next set of problems and solutions have more to do with how you go about telling CF to USE the new JVM once you have installed it (and whether you may have made one of the mistakes above first, and then found CF not starting after that.)

• Problem: You may have pointed CF to the wrong JVM location (whether you put that location path into the CF admin or the jvm.config).

  Solution: Point CF to the right JVM location. But there are some gotchas, which I discuss here and in the next "problem".

  For instance, if you are installing a JDK, you should point it NOT to the location of the JDK itself (like C:\Program Files\Java\jdk1.7.0_71) but to the JRE directory within that folder (and yes, a JDK has a JRE within it).

  So that on Windows, for instance, with a Java 7 JDK, you'd point to C:\Program Files\Java\jdk1.7.0_71\jre. (Well, technically if you're editing the jvm.config it would need to be specified as C:\\Program Files\\Java\jdk1.7.0_71\\jre. See the related point below.) In Linux, the path may be something like /usr/java/j2sdk1.7.0_71/jre, for instance.

  (Interestingly, if you use the CF Admin "Java & JVM" page to enter the path in the "Java Virtual Machine Path", you can put the path in without the /jre and it not only accept it, but it uses it correctly. Under the covers, it changes the jvm.config to append the /jre for the java.home value. Curiously, though, while you'll see that reflected in the CF Admin pages "system information" and "settings summary", the "Java & JVM" page will still shows the path without the /jre (if you entered it that way here.)

• Problem: You may have forgotten to change the path's directory separator slashes, on Windows

  If you're on Windows, and made the change to the java.home location in the jvm.config (as described above), beware that you can't just drop the path in as it's reported by Windows. You need to change the directory separator slashes, to either of two options.

  So where the actual windows path may be C:\Program Files\Java\jdk1.7.0_71\jre, you should change that to C:\\Program Files\\Java\jdk1.7.0_71\\jre (two slashes) or you can use the other slash: C:/Program Files/Java/jdk1.7.0_71/jre. This is just a "java thing", a vestige of its *nix heritage it would seem. (BTW, one advantage of using the "java & jvm" page of the CF admin is that it takes care of this correction to the slashes--but it comes at the cost that if you point to the wrong JVM location, as discussed two points above, then you can't use the Admin to correct that mistake, because CF won't start. You'll then need to edit the jvm.config, as discussed in the previous point.)

  And note that you do not want to leave a trailing \\ or / (depending on your choice above) or you may find that when you try to visit the CF admin "Java and JVM" page, you get an error, "Element JDKPATH is undefined in FORM". And you may find that it also causes errrors on other admin pages, of the sort "String index out of range: -1 null".

• Problem: You may have made one of these mistakes, and now CF won't start, so you can't see the CF Admin to correct your mistake

  So perhaps you installed the JVM and pointed CF to the new JVM location using the CF Admin "Java & JVM" page, but having made any of the mistakes above (so that it points to an incorrect JVM), you find that now CF won't start and so you can't access the CF Admin. What do you do then?

  Solution: Well, there's really good news here. Changes you make to that CF Admin page are simply put into their respective place within the jvm.config file CF uses. Specifically, it edits the java.home line (usually the first non-commented line in the file). You need to find that file, and correct the path to be the correct location.

  Where that file lives depends on the version of CF. In CF10 and above, it's in [coldfusion10/11/2016]\cfusion\bin.

  In CF9 and earlier, with a server or Standard deployment, it's in the [coldfusion9]\runtime\bin directory (wherever you installed CF).

  And if you are using multiple instances of CF, then that's worthy of its own discussion (including where to find the files). See the next point.

• Problem: You may have updated the JVM config for the cfusion instance, but not your other instances

  If you are running CF Enterprise (or Trial or Developer edition) and are using multiple instances (what CF9 and before referred to as a "multiserver" deployment), note that you must change the jvm config affecting each instance that you want updated. Especially in CF10 and above, where each instance has its own jvm.config, it's not enough to just update the main "cfusion" instance.

  Solution: Let's talk to those using CF10 and above, first. As you may know, each instance has its own jvm.config, and you'll find it in the [coldfusion]\instancename\bin folder. So just be sure to make the needed JVM config changes for each instance.

  In CF9, things were more challenging if you had multiple instances (supported by the Enterprise edition and its multiserver deployment option). First, there was ONLY ONE jvm.config, by default, and all instances shared it. Also, only the cfusion instance's CF Admin had a "java & jvm" page (in CF10 and above, each instance DOES have its own "java & jvm" page, also).

  So by default, in CF9 and below, there was just the one jvm.config file, and it was found the jrun4\bin directory. And if you were to edit that one file it would affect all instances.

  Note that it IS possible for someone to have configured separate jvm.configs for each instance, in which case you'll need to edit each. That's beyond the scope of this entry, but I discussed it here.)

• Challenge: You may have told the Java installer to install itself WITHIN (or extracted the zip) the CF JRE directory. I will argue that you should be very careful about doing that.

  Recommendation: When you run the Java installer, it may ask (or you may tell it) where it should install itself (or when you extract the JVM zip install option, you tell it where to extract to). And you may be tempted to tell it to install itself into the JRE directory within CF, for instance, the C:\ColdFusion2016\jre in Windows? You not only don't NEED to do that, but I would argue you be very careful if you do.

  Indeed, this one may be a bit debatable by some. So notice it's listed here as a "challenge" with a "recommendation", rather than a "problem" with a solution. It's something I see many do, either based on someone's recommendation or just because they think it makes sense. While it may not keep CF from running, it can in certain situations.

  But bottom line, you MAY have problems (any of these here).

  For example, note that if you extract that zip of a new JVM into the existing one, that extraction will NOT REMOVE what was already there. It will only replace it. That would be bad, as there may be remnants of things from the old JVM that should NOT remain in place with the NEW one. Same with the jvm installer (though thankfully JVM 8 installers now throw an error if you try to install into a non-empty directory). At least whith this problem, you could stop CF and RENAME the current JRE directory, then put the new one into its same place.

  But do beware not to DELETE the old JRE, tempting as that may be. You may want or need to revert back to the old one! And you can try to uninstall the "wrong" JVM (if that's what you did) and install a new one, but even that will still leave you unable to go back to the original, if you have told the JVM installer to put itself into the CF jre directory (not to mention it's also easy to get wrong exactly WHAT JVM to get--JRE or JDK--and then WHAT folder under CF to "put that in").

  Instead, this argues that you really should just install the new JVM outside of the CF JRE folder, and then point CF to that (either using the CF Admin or by editing the jvm.config), as I have discussed above. That way, if you wanted to get back to the original JVM, you can just swap comments in the jvm/config and switch back to it pointing to the original CF jre folder (like the C:\ColdFusion2016\jre.)

  If at this point you DID already make this mistake and are having problems recovering from it (perhaps even having messed up CF's JRE folder badly), you may be best just reinstalling CF, or if you have a system backup (or VM snapshot), perhaps you can recover the CF directory to as it appeared before you started this effort.

And what follows now are more issues that may arise AFTER you have made the update (perhaps avoiding all the mistakes above), but where you find that while CF comes up and some pages work, some other pages (perhaps the CF Admin, or certain pages of yours doing certain operations) may fail. The first two apply more to older CF and JVM versions, but the next ones may apply to later versions also, as explained there.

• Additional step that may be needed, for Windows: Beware that when you update from a quite older to a newer one, you may find that CF won't start. As I discuss above, when you run the cfstart command from the command line (as a diagnostic step), you may get a popup message saying some named dll "is missing".

  If so, you need to copy that dll file from one of the JVM's folders into one of CF's.

  This has been discussed by Adobe in the past, such as in a technote from the CF 9 era, when it added support to switch from Java 6 to 7 (where the error may report "MSVCR100.dll is missing"). It can also happen when switching from Java 7 to 8, 8 to 11, and even within a given Java version from a very old update to a much newer one (as I had someone experience going from Java 8 update 25 to update 281, when the missing file was vcruntime140.dll.)

  Whatever file is named, again you need to you need to copy that dll file from one of the JVM's folders into one of CF's, because CF is looking at a folder within CF where CF is started, and the installation of the new JVM won't "put it there".

  • As for where to FIND it: if you had installed a JRE, you should be able to find that named file in the new JRE's bin folder. If you installed a JDK, it should be found the jdk's jre\bin folder.
  • As for where to PUT it, you want to put it in the same folder as CF's jvm.config file: on versions of CF from 10 and up, that would be CF's cfusion\bin, or the [instancename]\bin if running multiple instances. On CF9 and earlier, you would put it in CF's runtime/bin folder, or in the [jrun]\bin if running multiple instances.

  So there you have it. (And while you should NOT update CF9 to use Java 7 until getting CHF 4 in place, I'll just say that if you do, this problem would apply to you as well.)

  You can see still more in this blog post from Jochem Van Dieten the 2008 era.

  (And this could happen with later versions of CF and the JVM. It's usually more of an issue when you are jumping from CF using a quite old JVM to a newer JVM.)

• Additional step that may be needed: You may need to copy a needed tools.jar file from one of the JVM's folders into one of CF's.

  Especially after updating the JVM from one major version to another (like Java 6 to 7 or 8, or Java 7 to 8), you may find that web services (cfinvoke, cfobject, createobject) don't work.

  This is similar to the last issue, of course, and is covered in an Adobe CF team blog entry, where they wrote: "If you are using ColdFusion Web services you will have to do a one-time change manually. You should copy tools.jar manually from {JDK8_Home}/lib to {cf_install_home}/cfusion/lib/. ColdFusion Web Services will fail if this is not done."

  Yes, the refer there to Java 8, but again this may happen if you are going from any major Java version to another (6 to 8, 7 to 8), and it may happen with minor JVM updates, though I've not heard of it. (And it may well be needed when in the future CF supports a Java version beyond 8.)

  To simplify things, if there is a tools.jar in CF's cfusion/lib folder already, you will want to replace it with a newer one if found in the new JVM's lib folder. (If you "save off" the old one in the same directory, do NOT just call it tools_old.jar, as Java will still find and load any .jar file in a directory it looks in, so if anything, rename the old one tools.jar.old.)

  Also, note that you do need to do that for each instance you may have, not just /cfusion (that tip was written by Adobe presuming one had only the one cfusion instance.) And of course, you do need to restart CF once you put this new file in place.

  But you're not done. See the next steps...

• Additional step that may be needed: You may find that you will need to delete the files that were created by CF when it compiled and saved your CFML into Java class files.

  This is again an issue that can happen especially after updating the JVM from one major version to another (like Java 6 to 7 or 8, or Java 7 to 8, or 8 to 11)Here's the issue.

  When we use the "save class files" option in the CF Admin (which is on by default, and recommended for production), CF will compile and save (to the wwwroot\WEB-INF\cfclasses folder) a class file for each cfm and cfc file, and one also for each function or method in them. The issue is that when those were compiled and saved with the older JVM version, something about that Java code (in the class files) may be incompatible with the new JVM. You won't see the problem until a CF request causes that older java code to be loaded, and then you may get some odd error.

  The solution is simple: just stop CF and find the wwwroot\WEB-INF\cfclasses folder (under your cfusion and other instance folders you may have). You COULD delete all the files in the folder, or you could even delete the folder.

  But the easiest thing is just to rename the folder (while CF is down). You don't even need to recreate the folder, as CF will do it. (But be careful NOT to delete or rename the similarly named "classes" folder in that same directory.) Then restart CF.

  This will force CF to simply recompile templates as they are executed, using the new JVM. (There should be little observable impact of this one-time action.) And to be clear, this deletion of the cfclasses folder is not always a necessary step, but there have been times when certain JVM updates did warrant this.

• Additional step that may be needed: You may need to delete the Java "stubs" created by CF in the past when calling web services.

  There are still other locations with compiled Java code (based on your files), similar to that discussed in the last issue. This one is related to whether your CFML code calls out to web services (via cfinvoke, cfobject, createobject), regardless of whether those called services are on your server or elsewhere.

  Indeed, Adobe specifically recommends this step (in an aforementioned blog post) that you "also make sure that the earlier stubs are cleared fom (sic){cf_install_home}/cfusion/stubs/ to get the newly compiled classes."

  What they mean is that if your CFML code had called web services, then CF would have created (compiled) Java stubs for those web service invocations. And they will have been compiled for the old JVM and so should be deleted as they may be incompatible with the new JVM. The good news is that the stubs will be recreated when any web services are next invoked. (It would be wise to stop CF, delete the stubs, and then restart CF.)

  Here's a fragment of at least one kind of error one may get if you don't do that update of the tools.jar (in case showing this here may find others find this post in the future): "cannot access java.lang.Object bad class file: java\lang\Object.class(java\lang:Object.class) class file has wrong version 52.0, should be 50.0".

• Additional step that may be needed: You may need to delete the rest-skeletons and cfc-skeletons folders where CF had compiled other files

  This is much like the last point. There are still other folders where CF may compile and save java class files formed from your CFML (or based on calls made by your CFML). And when you change major Java version, CF could get odd errors because the old compiled code doesn't work with the new java.

  So do the same delete or rename of the folders you may find in the same folder as cfclasses above: the wwwroot/WEB-INF of each CF instance you may have (or the cfusion instance, if it's your only one). As with them, CF will simply create a new folder and populate files there as it needs to when it needs to.

• Additional step that may be needed: You may need to import SSL certificates into the new JVM--but beware, perhaps you don't NEED to!

  You may find that when you switch JVMs, your CF pages using CFHTTP and similar tags/functions to call https URL requests may start failing. It may seem like CF has "lost" the certificates.

  Instead, it's that when you change the JVM that CF uses, you are also implicitly causing CF to use that new JVM's java key store (where certificates are stored), which is used by the Java code underlying CF which is called when you make https requests from within CFML with CFHTTP and the like.

  And any certs you may have put in before would now NOT be available to the new JVM (and to CF), unless you put them into that new keystore.

  So a first step to determine whether this may be an issue for you, look at the jre/lib/security folder (or just lib/security for Java 11 and above), for whatever is the JVM that CF is currently using, to see if all the files listed there (including cacerts) have the same date and time as each other. If they do, then no change has been made and you can move on to the next step. If the date/time of the cacerts IS updated compared to others, then it indicates that someone HAS imported some certificates into that jvm.

  But before you just go grabbing all those certs to import again, beware that you may not really NEED them. Sometimes, the reason you had to add certs to the CF/Java keystore was that the JVM was indeed old, and the certs there may no longer have worked--and so you were told to get new ones. But in moving to the new JVM, perhaps that problem is alleviated.

  Update: Since posting this blog entry in 2014, I created a blog post in 2019 with more on this point: Solving problems calling out of CF via https, by updating JVM.

  I'd propose you confirm if you need any of the old certs at all first, whether by testing or by using the jvm keytool option to list the certs and compare what's in the old and new keystores.

  Further discussion of that (listing certs), let alone importing them, is beyond the scope of this blog post. But I will warn you to be careful to note that many instructions on the web for using the keytool (to add cert to the keystore) presume that you are doing that import into the keystore WITHIN THE JVM THAT CAME WITH CF. If you have changed the JVM, as discussed here, then clearly that is NOT where you want to import them (if you need them at all).

  Fortunately some such resources do go that important step further and warn you that if you have changed the JVM CF uses, you need to be sure to update that JVM's keystore and they show how to do it. So just pay close attention.

  Finally, DO NOT just copy the keystore (cacerts file) from the OLD JVM to the NEW one! That's quite unwise because the base keystore in the new JVM could have been significantly updated (for the better), and your copying over that would lose those improved base changes.

• Additional step that may be needed: You may need to carry forward files placed into the bin folder of the JVM that CF was previously using

  This is somewhat similar to the previous point. While that talked about SSL certs that someone MAY have imported into the JVM that CF was previously using, this one is about various OTHER files that MAY have been placed into the bin folder of the JVM that CF was previously using.

  For example, when using the Microsoft SQL Server JDBC Driver (one where you would have to manually implement that JAR into CF's cfusion/lib folder), if you may try to use "trusted authentication" with that, you will find that you may have needed to ALSO implement a certain dll file (that comes with that driver) by placing it into the jre/bin folder of whatever is the JVM CF was using. An example is mssql-jdbc_auth-8.4.1.x64.dll, but of course that name could change based on your driver version, OS, and you may find something similar for some other database. Or there may be a DLL placed here for some other "special" reason that CF required it (and while obviously a dll would be only on Windows, there may be a similar file of some other extension on Linux).

  If you did place such a "special" file in that bin folder of your previous jvm (if you find a dll in that jre/bin folder, which has a date/time different from all other files there), it would seem you should copy that dll to the new JVM's jre/bin folder. (If you are using Java 11 or later, the JVM IS a JRE by default so it would just be the bin folder under that new JVM, such as C:\Program Files\Java\jdk-11.0.9\bin.) If you do that, note that you need to restart CF for it to pick up that change.

  In this situation, I can't say FOR SURE what you should do, but what I have shared here should be the solution if you don't do this, and instead you that (after updating the JVM) some of your CF datasources (using that MS-provided SQL Server driver) get the error, "This driver is not configured for integrated authentication".

• Additional step that may be needed: You may also want to edit the Solr (or technically, the "jetty") jvm configuration file, so that it points to the new JVM.

  I won't say I know it's happened, but you may find that after updating the JVM, certain things in CF don't work related to the integration of CF and either Solr (though tags like CFSEARCH, CFINDEX, and CFCOLLECTION) or the new PDFG feature (in CF 11 above, using CFHTMLtoPDF). These make up what CF calls the "add on service".

  And the issue is that the configuration under the covers of this add-on service (technically, Jetty, bundled within CF) points by default to the JVM that is built into CF.

  If you want to change that to to point to the same new JVM that you have pointed CF to, you would edit this file: in windows, the jetty.lax file; in linux, the cfjetty file, which would be found in CF's cfusion/lib/jetty folder. You'd edit that file's lax.nl.current.vm. Note that it points to a javaw.exe in the jre/bin folder, which is different than the jvm.config. I discuss this more in a comment below.

So phew, that's a fair bit, but forewarned is forearmed. Hope that lists helps someone. If you have other ideas, fire away.

I've added here some of the various error messages people get in these scenarios, to help folks find this post if they go searching for them later. I welcome hearing from folks who may already have more such error messages on hand for me to add.

Before we wrap up, there are a few miscellaneous related points I do want to make.

Beware: You may find also that CF won't even STOP, if you make some of those mistakes above

I mentioned earlier in the entry that if you make some of these mistakes, you'll find that CF won't even STOP let alone start. That's important to understand, when editing the JVM configuration.

Many don't realize it but when you "stop CF" it kicks off a Java process which reads the same jvm.config file used to start CF, so if you make one of those mistakes above related to configuring CF to use the new JVM, and then you try to restart CF, you may find it won't stop let alone start.

In that case, you'd want to use your operating system to kill the cf process (coldfusion.exe or coldfusion in CF10+, jrun.exe or jrun in CF6-9). Then set things right using the info above, and then try starting CF again.

How to go about updating the JVM

So after all that, someone may say, "ok Charlie, but could you also tell us how to update the JVM?" Again, the focus here was "you already tried it, and it failed. How do you recover". As much as I'm tempted to outline here how to go about it, honestly there are several resources that already do it, with varying degrees of detail (and some showing different approaches), so I'd rather point to them here:

• Nice, recent,several-minute Youtube video walkthrough of the process, from Pete Frietag
• How to change/upgrade JDK version of ColdFusion server, a recent blog entry from an Adobe engineer
• Upgrading ColdFusion To Java 7, a classic from Ben Forta (from the Java 7 timeframe, so perfectly useful still)
• Upgrading the ColdFusion JVM on Linux and Windows (still more detail, from Ryan Stille)
• Updating the JVM version for Coldfusion (Linux) (some more Linux-specific details from Keith Mitchell)
• Ask-a-Muse: How Do I Upgrade the JVM? (some more detail from Mark Kruger)
• my own article, with some other details of interest if updating, though more relevant back in CF 8/9, when Adobe first authorized updating the JVM beyond the version those came with
• How to change the JVM for ColdFusion on JRun (a quite dated reference, but which being old comes up high in google searches)

There are still others, and perhaps better ones with clear walkthroughs and gotchas. I welcome additions.

Again, it really should be quick and painless

I'll just say in summary that again changing the JVM which CF uses should really be just a 5-minute job.

In brief, you install the JDK (to a directory outside of CF), you change the jvm.config to point to the new JDK's JRE directory (saving a commented copy of the line pointing to the original one), save that file (don't close it), and restart CF. If anything goes wrong, go back to that file you just saved and see if you made one of the mistakes above.

And if you're still in a bind, do look to the CF logs to see if you find an explanation. (In CF9 or earlier, rather than the logs director though, when running CF as a Windows service, see the coldfusion9/runtime/logs or jrun4/logs.)

Finally, if you are really stuck, contact me for what may be just a quick consulting session. If I can't help, you won't pay for the time. I offer a satisfaction guarantee for my assistance.

So what JVM is supported by what versions of CF?

I mentioned above that one problem people get in trouble with is they try to update the JVM to a version that is not supported by their version of CF.

For instance, certain CF versions support certain Java versions (like in the case of CF10 and 11 supporting Java 8 only after you have applied certain CF updates (updates 14 and 3, respectively).

[Update: here's good news. I have created a post with a table of what versions of CF support what versions of Java, updated as of 2021.]

And while CF supports Java 7 in CF11 by default, it only is supported for CF10 after applying update 8, and for CF9 only after applying a certain CHF (the CHF number depends on the point release of CF9 you're running). For more, see this Adobe blog entry.

Fortunately, the CF team has recently come out with a blog entry on this very subject. Do check that out. (Update in Oct 2016: they created yet another post which is a bit more updated.

One last gotcha: Beware the Java installer's "public jre" option

One last point (this is a new one I've added since I first wrote this post in 2014): 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 (not wanting the "java" command being executable from any directory on your server), AND also--most important to the above--to prevent Java from later prompting you or someone else to let it update itself, which then could break CF.

I started to add my reasoning here but decided to create a new blog post, Why you should think twice about leaving on the "public JRE" option of the Java JDK installer . See that for this additional important info.

You can get help if you need it

Phew, that's a LOT of stuff to consider about updating the JVM that CF uses. And yet so often when you see discussions of it, those never get into these details. Hope they have been helpful.

Again, if you need help with anything above (and want more than just to ask a question as a comment here), reach out to my via my consulting services, where I can help remotely and usually quite quickly as well as safely and easily (even if you "can't allow remote access"), and with satisfaction guaranteed.

But of course I do welcome questions and comments here. I do hope this is a useful blog entry and that you may even share it with others, as the subject is one that many trip over but few may find just by me posting it here.

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed