I meant to post this ages ago when it was more relevant, but it got buried in my in box.
Back when I posted the article "CFSummit: interesting ColdFusion 2016 stuff " (whilst CFSummit was actually on!), Micha from Railo responded with his own thoughts on what Adobe had said.
I really appreciate how much time Micha puts over to helping me on this blog by following up various things I raise or wonder about. His community approach is definitely something the guys from Adobe could take note of.
In this case I think it's pretty interesting stuff, so I'm going to reproduce his comment here, in case people missed it the first time.
Again, sorry to not do this straight away when it was more fresh.
I've adjusted this slightly for formatting, but otherwise it's the same copy as per Micha's original comment:
Adam was asking in our mailing list about what we thinking about this, so here my comments.
"Modular nimble engine"Like you know, we support the possibility to install/update/remove Extension from within the Railo admin. We work hard to improve/extend that functionality for Railo 5 (dependency, OSGi based ...) and we will remove stuff from the Railo Core and move it to Extension, this includes
- ORM (Hibernate)
"Enterprise class package manager"Sounds like our Extension Providers ;-)
the only thing not supported is "info about package exposed as a REST webservice", but we support http/soap webservices ;-)
"Focus on optimized performance on JVM"Our main focus from day one!
"Breaking backwards compatibility"Is this a feature ;-) Check all the settings we have in the Railo Admin that have exactly that purpose, making something right instead of compatible.
"Anything with quotes is a string, scope search"sound like they finally remove that ugly key interpretation, hopefully.
variables["request.susi"]="Sorglos"; echo(request.susi); // works in ACF!!!
or is it the following
<cfif "1="" "2001-01-01"="" 1="" 2001"="" eq="">equal</cfif> outputs "equal" in ACF, becuause ACF
assumes with every string comparision that the operants could be dates and is checking for this, always!
Both examples are not supported in Railo, because they are simply stupid (my personal opinion)?
So hopefully they get Railo compatible here ;-)
"Increased support for OOP - retain simplicity"what does this exactly mean?
what we have are settings in admin like "remove 'variables' scope from components" or "set data member default access (this scope variables) to 'private'"
"Tighten interface implementation"From my personal opinion interfaces in a dynamic language like CFML makes no sense, because they only make sense in a static language like Java.
With Railo 5.0 we adding support for polymorphism modifiers like "abstract" and "final" for Functions.
"Collection datatypes"What does this mean? Struct and Array are Collection data Types.
btw: in Railo you can loop arrays and structs with cfloop-collection from day one, because both of them are collections ;-)
"New logging framework"we plan to move to log4j in Railo 5.0
"Create WAR and deploy anywhere"We have a tag (alpha) named cfdeploy, that allows to deploy code to a remote server or locally as war or simply the files.
Producing war is not a big deal, main focus of this tag is that you can define which parts of the code get compiled.
So what is this really about, a war is nothing more than a zip file, containing cfml files and static resources and a WEB-INF folder that is defining some local rules, the war can contain Railo or not. You can download a war from our download section and extend with you own code. no magic here.
"Image manipulation revamp"Current "implementation" is only a wrapper for the unerlaying apache library, with no CFML spirit at all, so this makes sense, hope this time the interface will be more cfml like.
"Extending the language"sounds like our CFML or Java based tags and functions that can be deployed to a railo instance and get core functionality. In addition we have a lot of interfaces to replace core functionality in Railo, you can add your own
you can even replace the ORM and the "Search" Engine, if you like.
"Concurrency - synchronized functions and blocks"we already support the attribute "synchronized" for the tag cfcomponent, when we added this, we decided that having it on the component level makes it easier to handle than on function level,so you synchronize every access to a CFC, in Java i have seen a wrong handle of this feature more than once.
"Concurrency - Concurrent Data structures"Since Railo 4.1 all struct and scopes are concurrent safe!
We have a modified Version of the ConcurrentHashMap, modified means improved for our environment for faster execution.
"Concurrency - Atomic variables and none blocking IO"We have a ongoing discussion about this in our mailing list, i think what really need is a easier way to use multithreading in general. funny is that the same was already done with cfmail long before cfthread was introduced (attribute spoolenable).
why has cfmail such a attribute but not cffile, what's about cfquery,cfftp,cfpop,cfldap, cfhttp ....? Every functionality communicating with resources ousite the JVM needs this.
i really think we need a general solution that is easier to use as cfthread.
My ConclusionYou not only will see a lot of this stuff in Railo in the near future (Railo 4.2 Beta is coming soon and Railo 5 is in work for some time now), you can already find a lot of this in the current Railo release!
What I'm seeing here is that Railo is already there with a bunch of stuff, and ColdFusion will be playing catch-up. Bear in mind that Adobe are talking about this for ColdFusion 2016... we haven't even seen a public beta of 11 yet, so I'd be expecting ColdFusion 11 to be out early quarter 2, 2014; and ColdFusion 2016 not until 2016! And how much further will Railo be ahead by then!?
I think Railo will continue to beat ColdFusion to market with meaningful additions to CFML: any of this stuff that they think will be good will probably be in Railo whilst we're still puzzling over <cfclient> in ColdFusion 11, and Railo will at the same time be adding their own useful features to CFML.
Thanks so much for your feedback here, Micha.