Railo: The Bigger Picture - CFML on the JVM
Disclaimer, this is my vision - not necessarily that of Railo or JBoss
JBoss and SpringSource
Generally there are two "communities" in the Java world - the Enterprise Java Bean (EJB) community and the "Plain Old Java Object" (POJO) community. JBoss is the leading open source provider of EJB technologies whereas SpringSource (the team behind the Spring framework) focuses on POJOs with the ability to add additional capabilities like messaging services and advanced transaction support on an a la carte basis.
In November of last year, SpringSource acquired g2one - a Groovy/Grails development company that includes the project leads for both the Groovy and Grails projects. Right now that's just a blip on the landscape. If you go to QCon or No Fluff Just Stuff you might think Groovy was the most popular programming language on the JVM. Speak to Java devs (even in the hallways at those conferences) and you'll find that it is in the very earliest stages of adoption for production applications.
What is interesting to me is that SpringSource now has a story for speeding up development using a dynamic scripting language on the JVM (Groovy). I would love to see JBoss looking at CFML as a competitive offering showing how JBoss customers could get the benefit of RAD scripting on the JVM without having to "leave the stack". Should that happen, I could see how CFML could get traction in the Java world with devs looking for a practical scripting language on the JVM with access to commercial support and a much longer track record than any of the other scripting languages for delivering production applications on the JVM.
I have no idea whether this will happen or not, but I certainly see it as an opportunity worth of pursuing.
I don't see java developers embracing CF in its current form. When CFScript gets badass, then maybe. Combine the simplicity of CF (1 line to do cfmail as opposed to the nastiness of doing it in java, even with Spring) with a more concise language and you've got a more compelling argument.
I do believe there is a use case and great benefit to ColdFusion but we need to look at benefit marketing vs feature lists and look what you can do presentations. We have gone way to geek. Getting people to play with something and watch a demo is nice. Helping them see what value ColdFusion adds to their lives and applications is where we will win them over.
@John, There are very good reasons why Java devs would consider a dynamic scripting language on the JVM for some part of their apps. The goal is to make CFML a credible option when compared to Groovy.
I know the tag based language in CFML is one of the big selling points for many existing and potential developers and it continues to be an important part of the language, but I'm glad to see cfscript getting some loving from both Adobe and Railo and I think that it will broaden the number of developers who will find a syntax that they are comfortable with inside the CFML community without detracting anything from those that would rather write all of their code using tags.
Earlier this week I was working on a new Eclipse plugin and needed to do some string parsing. I dropped commons.lang into the project, and off I went. It's *that easy*. If, as this imaginary seeking-conversion developer, I am considering CF as a replacement, I'll want to know that these libraries are -- let's be honest -- either not usable or are a pain in the ass to use.
For one, you have to javacast all over the place. For another, you're screwed when an Interface is required: Collections.sort(...Comparator..) in CF? Nope. Cuz you can't write your comparator in cfml, or even in java inline in your cfml.
If CF wants to compete in the "alternative languages on the JVM" space, I believe it will need to improve this story.
And this is just to get that small segment of developers willing to give up compile-time checking and IDE content assist, both of which they'd lose when moving to CF and still trying to use external libraries.
I know java devs that are looking for scripting language to be able to do things more quickly. The power you get from dynamic typing can make the difference on some projects between economic viability and a project that isn't worth building. I still remember seeing an old version of the JUnit code base using method overloading for assert equals and basically repeating itself for every possible type you wanted to assert equality for - to me that's too high a cost for the benefits of better IDE support and compile time error checking. I think there are use cases where a dynamic scripting language makes more sense and I'd love for CFML to be capable of consideration as an option for that. As to what will happen, we'll see.
Of course, being open source, if there's anything you think needs to be added I'd love to hear from you and get you set up with the ability to commit it :-) At least if there are specific things you think would be useful, add them to JIRA so everyone can look at them - maybe someone else will want to add them!