Note: This blog post is from 2021. 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.

Some good news is that ColdFusion offers simple ways/variables that can show you each of these, via the admin or via CFML code. In this post, I discuss both approaches, including a simple single variable which works in CF2018 and above, a variation for those on CF2016 and earlier, as well as variations for Lucee.

Background

There can be occasions when you may be trying to solve a problem, and the question may arise of what Java (JVM, JRE, JDK) version (and update level) is in use by your CF instance. Or you may be told you should modify some file in the JVM's location (like its lib/security/cacerts). And you may THINK you know what version and location is being used by your instance of CF, but people can sometimes presume incorrectly--or they be misled by others who presume the wrong thing or who may well be misled by unexpected configuration differences.

The multiple ways you can check the Java version underlying CF

While the focus of this post is on how to find your CF version via code, it is of course not the only way (though it may be the most reliable way to know for SURE what is the version for the CF server on which your CFML code is running).

Checking the Java version via the CF or Lucee Admin

Most people know (though not everyone does) that they can find the Java version underlying their CF instance by way of the CF Admin, using either the "Settings">"Settings Summary" page or via the "system information" page (accesses via the 'i" in the top right corner of the CF Admin). Same with the Lucee Admin, which shows it on the front page.

But perhaps you don't have access to the CF or Lucee admin--or you may mistakenly look at the WRONG CF admin, if you run more than one instance of CF (as I discuss further below).

Outputting the information via code, in the template where you have a problem (that may be related to the Java version in use) is the most direct way to know for sure what JVM version is used by THAT instance where the code is running.

Checking the Java version via code in CF2018 and above: CF's server.system.properties.java struct

The easiest way to see the Java version and the jvm's directory location (in use by the CF server where the CFML code is running) is to output the following variables--found within the server scope's "system" struct, which became available as of CF2018 and above:

You could of course use CFOUTPUT, CFDUMP, CFLOG or their cfscript equivalents, or whatever means you prefer for accessing/showing this variables.

And if you wonder about still other JVM characteristics, you could of course change it to a (or its cfscript equivalent, writedump) which will show ALL the variables that CF holds in that start with "server.system.properties.java"

You may wonder why I don't propose that you dump "server.system.properties.java", as the naming of the variables above suggests it would be a struct. But it's not. Instead, things like that java.version and java.home are in fact instead keys in the server.system.properties struct, as you will see if you do that dump.

Still other keys in that struct that may be useful are:

• java.vm.version - a more detailed indication of the JVM version, such as might be "11.0.14+8-LTS-263" (the value I see as I'm using 11.0.14, as I update this post a bit in Mar 2022)
• java.version.date - the date the JVM vendor (Oracle) indicated as the release date for this JVM
• java.io.tmpdir - where JAVA deems to be its temp directory, which could and almost surely WOULD be different from that pointed to by CF's gettempdirectory() function
• and there are several others, of seeming less value for our purposes generally

A variation for Lucee

Speaking of how these "java" properties in the server.system.properties are not a struct, users of Lucee will find that the simplified dot-notation syntax I offered above fails (at least in Lucee 5.3.7.48). But changing it only slightly (to refer to the "java." references as keynames in that struct) will work:

And FWIW, this other variation works in CF2018 and above, of course. CF has supported this array notation for key names in a struct since CF4.

Checking the Java version via code in CF2016 and earlier: use Java's own system.getproperty method

I mentioned that it was CF2018 introduced the server.system struct, and those on earlier versions can't use that. But They can instead obtain the same information by calling upon Java directly from within your code:

And this code works in Lucee, as well (and of course in CF2018 and above).

Some may wonder why I didn't just offer this since it's "more universal". Well, it is, but it's not as clean and simple.

Finally, some people may even find that the ability to invoke such java objects (as in this last example) is restricted in their CF administrator via "sandbox security". (To be clear, the ability to run this previous code is NOT precluded by checking the CF Admin setting, "Disable access to internal ColdFusion Java components". That instead is about limiting not just whether ANY java objects can be invoked but instead whether certain specific Adobe-provided Java objects (typically undocumented "servicefactory") can be invoked.)

How this Java version information could vary from your expectations

If the JVM version and/or location information turns out to be different from what you or others suspect (or from what you may argue you even "see" in the CF or Lucee Admin), there could be a number of explanations:

• you be running multiple CF instances of CF (possible with CF Enterprise, Trial, and Developer), and someone was judging things about ONE instance that they presumed was true for ALL of them)
• you may run CF and CF Builder--and since CF2016, CFBuilder has offered to install its OWN CF instance. You could be running your code against the CF instance that CFBuilder implemented and viewing the Admin of the CF instance, or vice-versa
• you may be using Commandbox, and again may be presuming that how you had one "server"/engine configured was universally applied to all of them (and it offers a simple argument to control what JVM is used with a given server/engine)
• and more

Again the main focus of THIS post is simply to make it easy for you to confirm WHAT JVM version you are using, so I don't want to go too far into the many potential explanations for things. But I will close with one more point, and with that I point to resources that may help you if you want to take things still farther (in understanding or resolving) JVM version issues.

If you decide to change your JVM version, some observations

If you may realize you have the wrong Java version implemented, perhaps you will have no choice but to go to the person who is responsible for your CF instance and present the evidence to them, and ask them to change things (if an updated JVM is needed.)

If you run your own CF instance, you may know that changing the JVM CF uses is relatively simple-- though things can go wrong. I have a post on the many things that can go wrong, and how to solve (or avoid) them. I also point there to resources to help you in performing the actual update. (Things are even more challenging if you may change from one major version to another--like Java 8 to Java 11. I address that in the post, as well.)

Or you may wonder what versions JVM versions are supported by the version of CF that you run. I have a (more recent) post on that, as well.

Finally, if you would rather just "clean up the mess" if things are incorrect, and/or you try to change things and run into problems, I can help with that, as I do about weekly with folks in my CF remote, online troubleshooting consulting. We can usually have the JVM version used by CF changed to a supported version, implemented correctly (and even setup to be easily reverted back) in a matter of minutes.

Again, the goal in this post was simply to show how easily you can find WHAT jvm version is used by your CF version...but the rest of the info is what typically flows from either wanting to know the version, or wanting to change it. Hope it was helpful.

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