Skip to main content
J
Junaid32092262a1i8
Participant
December 1, 2025
Answered

ColdFusion 2023 Boolean Type Handling Change - Undocumented Breaking Change?

  • December 1, 2025
  • 2 replies
  • 730 views

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)}} />



 

    Correct answer Junaid32092262a1i8

    @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.

     

     


    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

    2 replies

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    December 1, 2025

    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.
      BKBK_0-1764625389205.png

       

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    December 1, 2025

    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.

    /Charlie (troubleshooter, carehart. org)
    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    December 2, 2025

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

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    December 1, 2025

    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.

    /Charlie (troubleshooter, carehart. org)
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices