[Looking for Charlie's main web site?]

Confirming ColdFusion's Java version via CFML code

Have you ever wished you could confirm with 100% certainty what Java version is in use by the CF instance you are running? Or where the JVM's location is (in case you are told to modify files related to it)?

Some good news is that ColdFusion offers simple ways/variables that can show you each of these, via CFML code. In this post, I share that. I share first a simple single variable which works in CF2018 and above, then I offer 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 is in use by your CF instance. Or again 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.

Several ways to obtain the JVM version and location details

While the ColdFusion Admin shows this information on its "settings summary" and "system information" pages, perhaps you don't have access to those--or you may also mistakenly look at the WRONG admin, if you run more than one instance of CF.

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.

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:

server.system.properties.java.version
server.system.properties.java.home

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 "java" struct.

A variation for Lucee

Users of Lucee will find that the syntax above fails (at least in Lucee 5.3.7.48), but changing it only slightly to the following will work:

server.system.properties["java.version"]
server.system.properties["java.home"]

And that variation works also in CF2018 and above, FWIW.

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:

<cfscript>
system=createObject("java", "java.lang.System");
writeoutput(system.getproperty("java.version"));
writeoutput(system.getproperty("java.home"));
</cfscript>

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 may even "see" in the CF 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 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 things

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 corrrectly (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: 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
Comments
Copyright ©2021 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting