Copy link to clipboard
Copied
[Update 13 Dec]:
In the upcoming ColdFusion (2025 release), we will deprecate and remove certain features to enhance the overall experience, improve security, stay aligned with the latest technological advancements, and eliminate obsolete libraries.
We announced the deprecations and removals on the ColdFusion pre-release forum a few days ago. If you haven't already signed up, please do so today
As part of this exercise, we have analyzed data from various sources and identified features slated for deprecation and removal. Additionally, we are updating the deprecation lifecycle and terminology by removing the "Retired" status.
Definitions
Impact of the updated deprecation lifecycle
These changes are part of our commitment to delivering a secure, modern, and efficient ColdFusion platform. Thank you for your understanding and continued support as we transition to these updates.
Disclaimer: Adobe values customer feedback and considers it when reviewing policies. Changes may be made based on this input. This serves as a general disclaimer, as updates depend on the feedback received, ensuring we can effectively support our customers.
What will be deprecated in ColdFusion (2025 release)
Feature |
Remarks |
CAR (ColdFusion Archive) migration |
Use cfsetup as an alternative. |
Java SecurityManager: SecurityManager was marked as deprecated for removal in Java Development Kit (JDK) 17 through JEP 411, meaning it is planned to be fully removed in future Java versions. |
Java SecurityManager was used in ColdFusion Sandbox Security. |
Legacy Cookie Processor support from the cfcookie tag: Tomcat 10.1 had removed support for Legacy Cookie Processor. |
ColdFusion (2025 release) will support it to maintain backward compatibility. |
ssh-rsa algorithm in fingerprint attribute in cfftp |
Deprecated due to security issues. |
MS Access and ODBC |
No active development. |
DB2 |
No active development. |
Event gateway features:
|
No active development.
|
What will be removed in ColdFusion (2025 release)
The features that will be removed have either been deprecated in a previous ColdFusion release, or due to Adobe Flash or Flex removal, or due to the core libraries no longer supporting the features.
Feature |
Why is it removed |
Mobile and all mobile-related features. |
No active development. |
License scanner: The License Scanner searches your local subnet to find other running instances of ColdFusion. |
The Activation page in CF Admin already tracks license usage. |
cfencode.exe/cfencode.sh utility, located in cfusion/bin |
Due to security issues and lack of recent updates. |
|
Adobe has removed Adobe Flash and Flex. |
CFMX_Compat encryption algorithm |
In ColdFusion 2023 Update 8 and ColdFusion 2021 Update 14, we’d announced the removal of the flag in ColdFusion 2025. The CFMX_Compat algorithm will also be removed. Alternatively, use any of the algorithms listed in the Encrypt function doc.
|
Thread support |
In ColdFusion 2025, we’ll upgrade to JDK21. JDK21 has removed the Thread.stop() method. To maintain compatibility, we’ll remove the terminate action in cfthread and the ThreadTerminate function in CF 2025. View this blog post for more details. |
COM/DCOM |
No active development. |
XML Forms |
No active development. |
All remaining Flash and Flex jars. |
Adobe has removed Adobe Flash and Flex. |
AWS S3- ACL |
Amazon has disabled access control lists for all new buckets starting in April 2023. View the post for more information. |
HTTP reason phrases |
Feature is no longer available since Tomcat 8.5. |
cfheader StatusText attribute |
Tomcat has already removed it. |
Axis1 |
Security issues. |
Sybase |
No active development. |
Jadozoom database driver |
No active development. |
The following table lists the features that will be removed because the features were deprecated in a previous version of ColdFusion.
Feature |
Deprecated in |
The value fire_now from the attribute onmisfire of cfschedule. |
Adobe ColdFusion (2021 release) |
cfmediaplayer tag |
Adobe ColdFusion (2018 release) |
cfscript support for script-based CFCs, such as query and storedproc . |
Adobe ColdFusion (2018 release) |
Service layer CFC's webservices, such as pdfs and images. |
Adobe ColdFusion (2018 release) |
GetMetricData parameter cacheops |
Adobe ColdFusion (2018 release) |
cftable function |
Adobe ColdFusion (2018 release) |
HTMLEditFormat function
Use the EncodeForHTML function as alternative. |
Adobe ColdFusion (2018 release) |
cfinsert attributes:
|
Adobe ColdFusion (2018 release)
|
cfselect attribute passthrough |
Adobe ColdFusion (2018 release) |
cfindex attributes:
Solr has removed these attributes. |
Adobe ColdFusion (2018 release)
|
cfsearch attributes:
|
Adobe ColdFusion (2018 release)
|
cfchart- format=flash |
Adobe ColdFusion (2016 release) |
The following UI tags based on YUI toolkit:
|
Adobe ColdFusion (2016 release) |
cfapplet tag |
Adobe ColdFusion (2016 release) |
cfcollection attribute path |
Adobe ColdFusion (2016 release) |
|
Impacted after deprecation of YUI and Spry libraries in ColdFusion (2016 release) Update 3.
passthrough was deprecated in Adobe ColdFusion (2018 release) |
ParameterExists function
Use the isDefined function as an alternative. |
ColdFusion MX |
GetTemplatePath function
Use the GetBaseTemplatePath function as an alternative. |
ColdFusion MX |
Spanish (Mexican) locale in SetLocale function. |
ColdFusion MX |
What This Means for You
We understand that these changes may impact your workflows and codebase. We encourage you to explore alternative solutions for the affected features as needed. The ColdFusion team is available to address any questions or concerns you may have and provide guidance during this transition.
What’s Next
We will keep you informed about future updates and are committed to supporting you throughout this process.
Thank you for your understanding and for being a valued ColdFusion user. We appreciate your continued trust in our platform.
Contact us
If you have any questions, feedback, or suggestions, please contact us at cf-deprecation@adobe.com
Copy link to clipboard
Copied
Historic changes involving quite some pruning.
Good work, Team Adobe!
Copy link to clipboard
Copied
While many readers may yawn at this list, some items will have far more impact than others--either because they're still likely quietly in use with people ignoring/not noticing the past deprecations (parameterexists vs isdefined, gettemplatepath getbasetemplatepath, the query cfc vs queryexecute; as well as cftable, htmleditformat and others), as well as the yui-based tags--that people could and did "unretire" by restoring the yui folder, per the cf deprecation page's instructions (which will be removed).
All these are finally REALLY going away, folks. REMOVED, not just deprecated. Such code will fail. And these aren't things which can be fixed with a global find/replace.
Others with likely significant impact are the removal of support for MS Access, Axis1, COM support, and more. While some will say they've "never" used them or not for "many years", I see people still using all those (in the community or in my support work). This will indeed be a "historic" version upgrade, as bkbk noted.
Further, there are a couple things not mentioned here that were discussed in the beta--and I feel comfortable saying it, for the sake of completeness (as it seems just an oversight here).
First, some good news: Adobe DOES plan to update the cfml code compatibility checker (in the cf admin) to identify all these changes. That will help many in preparation. Similarly, Pete Freitag has recently added compatibility scanning to his wonderful Fixinator tool (commercial), and I'd expect him to add all these to that feature.
Second (and finally, for those who've read this far), and bad news for some: the note above doesn't currently communicate something important regarding cfmx_compat. Not ONLY will the jvm arg be removed (which allowed reversion to that as the default), but also the ability to USE that cfmx_compat value for encryption/decryption will be removed. That was never clear from the discussions of the June cf updates that first addressed the change of default. But the discussion in the beta forum did confirm Adobe plans to remove this also, which again means work for the many who still use that. (I have a blog post at carehart.org from July as a follow-up to that update, elaborating on the impact of the change regarding cfmx_compat.)
I do hope that the table above will be revised to clarify that COMPLETE removal of cfmx_compat. (Sadly these removals are NOT yet implemented in the first beta, so we are still left to only anticipate what's been said here, versus actually experiencing it.)
And time will tell how truly significant the impact will be. For some, it will be inconsequential. For others... we shall see.
Copy link to clipboard
Copied
Kind of embarrassed to say we use a few MS Access databases yet, but they are not my projects thankfully. We're working to migrate those to MS SQL Server however.
Our biggest impact will probably be <cfinput autosuggest="cfc:">, which, yes, is YUI dependent. 🤐 It's just so easy to add that feature to more "basic", not much JS projects.
Question, will the compatibility checker updates come to CF2023? That way we can check existing code before testing on CF2025, migrating incompatible things as we go, before CF2025 release.
Copy link to clipboard
Copied
What is meant by the vague "Customizing an HTTP response" feature that is going to be removed? I'm not sure if this will affect us or not without more information.
Copy link to clipboard
Copied
It should have been "HTTP reason phrases have been removed." We used to get <status_code> <reason_phrase> in the response earlier. For example: 200 OK & 500 Internal Server Error
I will get the description updated.
Copy link to clipboard
Copied
ok, so only "200" (the status code) is returned instead of the combined "200 ok"? (When using CFHTTP, I would always evaluate this using val(cfhttp.statusCode) eq 200 which ignores the "reason" string.)
Does this affect both CFHTTP and CFHeader? I believe that CFHTTP should return whatever the target URL's server would return (ie, "200 WHATEVER IS CONFIGURED").
Custom content via the CFHeader tag (using the "StatusText" argument) is no longer possible in Tomcat 8.5?
I believe that CF2016 uses Tomcat 8.5.6 and was upgraded to 8.5.28 in Update 6. The "Statustext" feature does NOT appear to be removed in 8.5 as stated in the above notice. (Ex. If I perform a CFHTTP of a ColdFusion 2016 webpage, CFHTTP.Statuscode is returned as "403 this is a test" which retuns the custom statusText phrase.)
Did you mean to state that Tomcat 9 has this feature disabled? If so, which version? I'd like to explicitly test this so I can identify the best workarounds in order to be compatible with ACF in the future.
Copy link to clipboard
Copied
Excellent innavations.
To maintain compatibility with old applications, will it be possible to use Java17 or not?
Copy link to clipboard
Copied
Excellent innavations.
To maintain compatibility with old applications, will it be possible to use Java17 or not?
By @Paolo Olocco
Short answer: no. By this I mean: it might be possible, but it wouldn't be a good thing.
Your question mixes two separate factors: compatibility and version. Java and ColdFusion are two separate programming languages. ColdFusion's compatibility - backward or forward - depends on the ColdFusion version and Java's compatibility depends on the Java version. You should not mix the two.
However, ColdFusion uses Java. As such, it evolves along with the Java version. Any big changes in the Java language, such as in security or in the HTTP/TCP protocols, will have an impact on ColdFusion. That way, ColdFusion continually benefits from the new advances and features in the Java language.
That is the reason why new ColdFusion versions are customarily optimized to run on a recent Java version. Hence, if ColdFusion 2025 is designed to run on Java 21, it will be sub-optimal to run it on Java 17.
Copy link to clipboard
Copied
ill likely switch from adobe and coldfusion sadly due to the cfmx_compat issue. I have so many tables and passwords and other things that use this and to re create everything with new algos and stuff is just a waste and pain. I see not making it default unless you have the flag or force it but to just remove it all together is simply not necessary.
Copy link to clipboard
Copied
Hi @rickmaz ,
The cfmx_compat algorithm has served ColdFusion well, but is no longer secure and so is due for change. Therefore I would strongly advise you to replace it with the new algorithms. It is definitely not waste and pain. Improving your code in this way is actually an investment in the long run.
Not only ColdFusion, but every programming language evolves. Generally for the better.
We, developers, should therefore expect to change our software as time goes on.
In fact, if you think that you can avoid such maintenance, you are mistaken. Benjamin Franklin once wrote to a friend,
"... in this world nothing can be said to be certain, except death and taxes".
That is also true in the world of software: nothing can be said to be certain, except maintenance costs and end-of-life.
Research shows that 60 to 80% of the total lifecycle costs of a software application is spent on maintenance. For further information on this research, see the following:
Software Engineering Economics and COCOMO research by Barry Boehm
Software Maintenance: Concepts and Practice, by Penny Grubb and Armstrong A Takang
Software Cost and Effort Estimation: Current Approaches and Future Trends, by IEEE
Copy link to clipboard
Copied
A heads-up: folks might miss the importance of the phrase above, about how among the removals will be removal of "cfscript support for script- based CFCs, such as query and storedproc".
I had in fact highlighted in my first comment here (the day of the post), stressing how this meant (at least) that code using the query cfc (as in new query or other forms of cfc invocation) would need to be changed, such as to queryexecute. I should have elaborated a bit more regarding OTHER of the old "cfc-based tags for script" being removed, including how to find them and how to change them. I do that here.
As the phrase indicates, this removal extends to many more instances of tags which were originally implemented in script as CFCs (first in CF9, and more in 9.1). I list them below. And I have more to share related to this specific removal, which I hope folks will appreciate. (I realize it's a long comment: I was torn whether to do it as a blog post. Maybe I still will. This started out as a simple comment but grew as I wrote. I wanted to go ahead and get this out today, as it came up in today's Adobe webinar on CF2025.)
1) The point of this removal (of CFC-based tags as script) is that you will need to find ALL such occasions of using them (not just the one query or storedproc mentioned above). And then you will need to change them to the NEW forms of script support (introduced in CF11, for nearly ALL tags), which is documented briefly (showing conversion from the "http cfc" to the new cfhttp statement, as a representative example) here:
https://helpx.adobe.com/coldfusion/cfml-reference/script-supported-tags-and-functions.html
2) As for what tags were introduced as CFCs for use in script, in CF9 (which will be removed in CF2025), they were:
ftp (for <cfftp>)
http (for <cfhttp>)
mail (for <cfmail>)
pdf (for <cfpdf>)
query (for <cfquery>)
storedproc (for <cfstoredproc>)
These were/are documented here: https://helpx.adobe.com/coldfusion/cfml-reference/script-functions-implemented-as-cfcs.html
3) Then as for those added in CF 9.1, they were:
dbinfo (for <cfdbinfo>)
imap (for <cfimap>)
pop (for <cfpop>)
ldap (for <cfldap>)
feed (for <cffeed>)
And these were/are documented here:
4) Beyond those, I also found there are also these:
Indeed, if anyone might wonder "just where are these CFCs?" that were used for support tags as script, they are deep within the customtags folder of your CF instance, such as \ColdFusion2023\cfusion\CustomTags\com\adobe\coldfusion. And that's where I found these other 3.
5) FWIW the two docs for CF9 and 91 above DO clearly show how Adobe has been "deprecating" the use of these old cfc-based script implementations of tags since CF2018, as was also discussed in the deprecation guide since then as well.
Again, the main point here is that in order to move to CF2025 you will need to change your code where you may still use these old CFC-based forms of script elements to instead use the new form added in CF11, as I noted above is documented here. There's even more discussion of that CF11 change (with examples) here: https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-r-s/cfscript.html#Scriptsuppo...
6) Finally, I will note that sadly you can't just hope to "find all these" by doing a code search for each as "new http" or "new query", for example, because in CFML there are of course multiple ways to instantiate a CFC. Some coder in the distant past could just as well have implemented this "change of script to support tags via CFCs" by using the creatobject function or cfobject tag. In fact, examples of these are shown in that 9.1 doc I'd offered above. Heck, someone could even use cfinvoke (to call a method, even while instantiating a CFC).
7) As I said in my first comment here (the day of this post), some of these removals are going to be QUITE challenging for some folks--and sadly we can't even experience them yet if you DO join the beta, as they are NOT yet reflected in the beta 1. They are due to be reflected in the beta 2, due in early January.
Indeed, I fear it's going to be a bumpy ride, not just in January or whenever CF2025 comes out but especially when in the future people try to move to CF2025--whether from 2023, 2021, 2018, or older. Many I fear will have code that's not been touched for years but always "just worked" despite the deprecation of these (CFC-based tags for script) in CF2018, and some other things (like parameterexists, which was deprecated over 20 years ago). I hope this comment (or a blog post I may create) will be helpful to them in the transition.
(I'm not at all here questioning or raising for debate the removals. I'm aware of the other comments here and elsewhere on how "removing old cruft is a good thing for any language". I'm just trying to help people navigate the potential minefield.)