ColdFusion 2023 Boolean Type Handling Change - Undocumented Breaking Change?

[Junaid32092262a1i8]

I'm currently from ColdFusion 2021 to 2023 and have encountered what appears to be a breaking change in how ColdFusion handles boolean values when interfacing with Java methods and MongoDB operations.

The Issue:
In ColdFusion 2021, I could pass native ColdFusion boolean values (true/false) directly to Java methods and MongoDB queries without issues. However, in CF 2023, the same code throws errors unless I explicitly cast the booleans using javacast("boolean", true).

Example:

<!-- This worked in CF 2021 but fails in CF 2023 -->
<cfset mongoQuery = {"active": true, "$exists": {"field": true}} />
<!-- Now requires explicit casting in CF 2023 -->
<cfset mongoQuery = {"active": javacast("boolean", true), "$exists": {"field": javacast("boolean", true)}} />

[Charlie Arehart]

Junaid, I don't have an answer (yet), and while someone else may jump in with it, until then I have some thoughts to help us help you.

First, you've only offered what you did to CORRECT the seeeming problem, but you've not show code that DEMONSTRATES (or allows us to create) the problem. The latter could be helpful, since your problem may have a different explanation than being a simple bug. Also, you have not let us know what UPDATE of CF2021 (or 2023) you are running, which may be relevant.

You assert there's been a change in "how ColdFusion handles boolean values when interfacing with Java methods".  I'm unable to recreate that. As a demonstration, I have tested your two scenarios against a java method that accepts ONLY booleans (the isstring method of java.lang.Boolean):

<cfoutput>
#createobject("java","java.lang.Boolean").tostring(mongoQuery.active)#<br>
#createobject("java","java.lang.Boolean").tostring(mongoQuery.$exists.field)#<br>
<p>
#server.coldfusion.productversion#
</cfoutput>

This code works identically, with either of your two cfsets in place, and either in CF2021 or 2023.  Note that if somehow what was passed into that tostring function was NOT a boolean, Java would report an error to that effect. That seems to prove there's no change in what CF is passing. 

As such, it seems there may be more to the matter than what you propose (perhaps depending on other code you are using). So can you offer even just another few lines (that stand alone) to demonstrate what you're experiencing, so that we can not only better assess that but also perhaps even run it on our own? 

FWIW, we may even find that it's not a change in behavior in CF2023 per se....but instead, it may be one introduced in an update to that--perhaps even an update to CF2021 which you have not yet applied. To be clear, the latest update to CF2021 (as of today) is update 22, from Sep 2025 (which is also when update 16 for cf2023 was released). What updates are you running, for your tests on each of those? You can see it in code by dumping/outputting the CF variable, server.coldfusion.productversion, which you'll see I've added in the code above.

Finally, I'll note that I even ran the code against CF2021 as early as update 2, and it still worked (with either of your CFSETs).  That update is the oldest one available as a docker image provided by Adobe (at dockerhub or amazon ECR), which is one of the easiest ways to be able to run some code against old updates of CF (at least for those familiar with using containers).

Let us know what you think and what more you may be able to offer.

[BKBK]

Hi @Junaid32092262a1i8 , As far as I know, there was no change in the handling of boolean type between ColdFusion 2021 and ColdFusion 2023. You can confirm this yourself.

Do the following test, independently of your application, to help you isolate the root cause of your error:

1.  Go to https://trycf.com ;
2.   Select ColdFusion 2023 as engine and run the code
   

   <cfset mongoQuery = {"active": true, "$exists": {"field": true}} />
   <cfdump var="#mongoQuery#">​

   
    You will see that the code runs as expected. That is, without any errors.
   

[Charlie Arehart]

Bkbk, you've misunderstood. They're not saying the code they offer produces different results in the two versions. They're showing those as two variants of the one cfset that they felt were needed to solve their problem. It may make more sense if you reread their post from that perspective. See also my reply from a few hours before yours, which presented that perspective as well.

Or do you feel I have it wrong? If so, perhaps best then for us both now to await what junaid may have to say.

[BKBK]

Thanks for clarifying, @Charlie Arehart . I didn't misunderstand. But I can see why you think I did. I should perhaps have explained more.

@Junaid32092262a1i8 , The situation, as described, is not fair to ColdFusion. The code mentioned does not work in ColdFusion 2021 and then fail in ColdFusion 2023. So there is actually no breaking change. That a ColdFusion true is rejected by Java is not ColdFusion's responsibility.

A ColdFusion true is not necessarily the same as a Java true (as you have found out). ColdFusion is weakly-typed, Java strongly-typed. You should therefore convert the type of ColdFusion's variables into a type that is acceptable to whatever interface ColdFusion is communicating with. In this case, Java.

Which is why ColdFusion has Javacast.  As the documentation says, Javacast "converts the data type of a ColdFusion variable to a specified Java type to pass as an argument to Java or .NET object. "

[Junaid32092262a1i8]

Hi Both,
Thanks for the detailed replies, thats really helpful.
Could it be that coldfusion 2023 supports Java 17 and in moving from coldfusion 2021 to 2023, Java 17 is causing the issue?

[Charlie Arehart]

You wonder now if the cause of your error is the fact that cf2023 runs on Java 17, while  cf2021 runs on Java 11? Could that difference cause trouble? Sure. Especially with some specific Java library that might be sensitive to that. Cf itself is not. That's why cf2023 comes with Java 17.

But let's go back to my first reply above. Did you try the simple code I offered? It shows that Cf does NOT seem to change how it passes booleans to Java methods, as you originally asserted. It would be helpful for you to prove that it works for you like it did for me on both versions with both your cfset examples. If it fails for you, it would seem you would have some different problem for us to explore.

Assuming it DOES work, then please create a few-line example that standalone to demonstrate the error you get, so we can. We're all just guessing here until you give us more.

[BKBK]

Hi Both,
... Could it be that coldfusion 2023 supports Java 17 and in moving from coldfusion 2021 to 2023, Java 17 is causing the issue?

By @Junaid32092262a1i8

Good observation, @Junaid32092262a1i8 ! That might be the root cause.

[BKBK]

@Junaid32092262a1i8 , following up on your last observation, I made a discovery.
In ColdFusion 2021 as well as in ColdFusion 2023 (on Trycf.com), the code

<cfset mongoQuery1 = {"active": true, "$exists": {"field": true}} />
<cfoutput>
<p>
#mongoQuery1.active.getClass()#<br>
#mongoQuery1.$exists.field.getClass()#<br>
<p>
</cfoutput>

<cfset mongoQuery2 = {"active": javacast("boolean",true), "$exists": {"field": javacast("boolean",true)}} />
<cfoutput>
<p>
#mongoQuery2.active.getClass()#<br>
#mongoQuery2.$exists.field.getClass()#<br>
<p>
</cfoutput>

results in:

class coldfusion.runtime.CFBoolean
class coldfusion.runtime.CFBoolean

class java.lang.Boolean
class java.lang.Boolean

This tells us that:

1.  Inside the Java Virtual Machine, ColdFusion's True is represented by the "wrapper" type coldfusion.runtime.CFBoolean. This is conceptually similar to Java's wrapper, java.lang.Boolean, but it is Adobe ColdFusion’s own internal Boolean wrapper used by the CFML runtime. So, even though it wraps a boolean value, it is not the same type as java.lang.Boolean. This confirms my earlier statement: "A ColdFusion true is not necessarily the same as a Java true".
2.  ColdFusion 2021 and ColdFusion 2023 produce the same result. Therefore the root cause of the issue is unlikely to be the move from ColdFusion 2021 to ColdFusion 2023. In other words, a change in the underlying Java version from 8 or 11 to 17 is unlikely to be the root cause of the issue.
3.  The root cause is likely to be a change in the behaviour of the Java/MongoDB APIs that ColdFusion is interacting with, or a change in the way ColdFusion interacts with them.

[Junaid32092262a1i8 · Accepted solution]

Thanks BKBK.
The root cause was the following two missing JVM flags in cf2023 there were present in cf2021:
-Dcoldfusion.literal.preservetype="false/true" -Dcoldfusion.lang.mfunctions.enabled=false

[BKBK]

Wow, @Junaid32092262a1i8 , what an interesting find! The flag -Dcoldfusion.literal.preservetype is indeed relevant. 

Thanks for sharing it.

Are you sure about the flag -Dcoldfusion.lang.mfunctions.enabled? What does it do? Is there any reference to it? 
I have searched but cannot find anything on it.