What
next for ColdFusion
and JRun?
Could Flash one day run Java? Could
ColdFusion run on .NET?
Tim Anderson talks to Edwin Smith,
Macromedia Software Architect.
may decide to run on something
other than a JVM"
Edwin Smith is a key software architect at Macromedia. As his bio modestly declares, “His contributions to rearchitecting CFML for the J2EE and .NET platforms led to the ColdFusion MX product”. I was fortunate to get an interview with Edwin at Macromedia Devcon 2002 in Orlando.
Author’s note: References to Neo, coloured pills and the like make more sense if you’ve seen the cool movie, The Matrix.
How ColdFusion MX began
Tim: ColdFusion MX is a radical revision of the product. How did it come about?
Edwin: It started at Live Software. We were working on JRun and in 1998, 1999 we started this project called CF_Anywhere. We announced it, and Allaire gave us a call; and a couple of months later we moved to Boston and joined Allaire. We initially spent all our time putting out JRun 3.0. After we were done with that, in summer 2000, we looked at what our options were, and decided to resurrect the CF_Anywhere project.
Tim: Was there any debate about that being the right direction?
Edwin. Yes, total debate. We called it the red pill and the blue pill. The red pill was continuing to evolve the ColdFusion 4, 5, 6 codebase, and then to take the Neo project and make that a new product that didn’t necessarily have backwards compatibility, faster, with new capabilities, more powerful scripting, and squarely intended to sit on top of J2EE. All the J2EE servers are having trouble differentiating from each other. So this would be a new thing.
The blue pill was to have one product line, backwards compatible, with new features but also a major focus on compatibility. We took the blue pill.
Tim: The main issue with the migration from ColdFusion 5.0 to MX is compatibility with server-side COM components. Were you aware that would be a big issue?
Edwin: We had a rough idea of who was using COM and how much they were using COM. We knew that anyone using COM might run into issues. But we had tested it fairly well. There were issues that we found in testing but we weren’t sure what the severity would be. But the reaction from people was much bigger than we expected. We immediately retooled and our first updater fixed a lot of those COM problems.
We knew that COM would be hard. From an engineering standpoint, going from Java to COM is not trivial. We’re using a technology called J-Integra, which if properly implemented does a nice smooth bridge, but integrating that into ColdFusion is a challenge.
Tim: Were the problems to do with your interface to J-Integra, or J-Integra itself?
Edwin: It was to do with our interface. Essentially - and I don’t remember the exact specific details - it boiled down to instantiating new COM objects more often than necessary.
Tim: I didn’t realise until I attended your ColdFusion Under the Hood session [at Devcon] that you could do thinks like calling Java methods on ColdFusion variables. Is there any reason why you can’t just embed Java code into ColdFusion, the same way you can with JSP?
Edwin: Actually, an early version of NEO did do that. We decided not. What it boiled down to is that when you have Java in a JSP page you have two languages on the server, the JSP on the server, and the Java on the server. Then they’re layered together into one running program. If you want to give the user good error messages, good context and good optimization, then dealing with two languages interleaved like that is not very nice. We didn’t want to write the equivalent of a Java compiler as part of the product. We did want to have this really great reporting, and good internal model. That’s the engineering answer.
From the customer’s point of view, it was a story that didn’t make sense. You have CFScript and you have the tags, and those are easy to learn. That’s one language. And you have JSP. We integrate with JSP. The two worlds connect, and JSP can do what JSP does very well, and we do what we do very well, and it’s a much cleaner picture.
Java, ColdFusion and .NET
Tim: Does your compiler emit byte code directly from ColdFusion CFML, or do you convert it to Java and then pass to the compiler?
Edwin: The current version produces Java source code, compiles it, and we load the byte code back.
Tim: So aside from the debugging it would technically be easy to embed Java code in the CFML?
Edwin: Well, it would just parse right through. But it would be difficult to provide good error reporting. We would have some things you could do that would break the embedded Java code. We could have code that happened to generate the same variable name as something you wrote. So suddenly you use the variable and bam, you get some error message that we can’t explain.
The other thing is that in future versions we most likely won’t be generating Java source at all.
Tim: So you will go directly to byte code?
Edwin: Hypothetically, at some point we may decide to run on something other than a JVM. Again, it doesn’t make much sense to have Java source in there and then take it out again later. So we took the purist route.
Tim: Are you hinting at the possibility of compiling to MSIL as an option?
Edwin: I’m not hinting that we’re going to do it, but ... we had a design decision to make. We said, well, we can’t say we’re not going to do it. So we want to leave our options open.
Tim: That would fix people’s COM problems.
Edwin: Yes, COM would definitely work better.
Tools for JRun and ColdFusion
Tim: There’s quite a lot of debate here at Devcon about the right tools for JRun. Macromedia had a nice Java tool called Kawa, which could have been adapted to handle CFML as well. Why was it dropped, when competing app servers mostly have a close association with a particular tool that has good integration features?
Edwin: We had to focus. Kawa was a Java IDE that needed to compete in the Java IDE market. We didn’t have the resources to compete seriously. It would have been too hard. Today, I’m looking at Eclipse and IntelliJ IDEA thinking, “Those are amazing IDEs.” If I was using Java every day in my job, or even JSP, one of those two tools would be the one I would pick.
On the other hand, if I were doing web design most of the time, even with Sun JSP, I would pick Dreamweaver. The databinding and the database integration in Dreamweaver is much better than anything we had in Kawa or anything we had in Studio. We pushed the Dreamweaver schedule back by six months to get a lot of the Homesite features in.
Tim: Admittedly Dreamweaver MX is a massive improvement from a developer perspective.
Edwin: Right. Further, some of the gripes I agree with. It should be faster and I would like it to be faster. But as the development team iterates, they will get it faster.
Tim: You mentioned Eclipse, and Macromedia is on the Eclipse board. Will Macromedia produce an Eclipse plug-in for JRun integration?
Edwin: We don’t have any plans that we’ve announced.
JRun and J2EE
Tim: You mentioned the difficulty in differentiating J2EE application servers. What does differentiate JRun?
Edwin: We’ve tried to keep it small, fast and easy to manage. So compared to the big three [IBM, BEA, Oracle] it’s smaller, faster and easier to manage. That’s just my anecdotal version of “faster”, rather than specific benchmarks. Then compared to the others, we’ve done really good integration with Flash, and we have some unique cluster management features. We use Jini for clustering, which is a very simple way to get a cluster up and running. Any node will come up and discover its peer nodes. Even the cluster management server itself is clustered, so there’s no single point of failure. Using Jini for that makes it easy.
So the differentiation is that we focus on making the management side easy. But as far as the APIs go, they’re all standard, just like everyone else.
Tim: I was impressed with the JMX support.
Edwin: Credit there goes to Sean Neville. We hired him at the beginning of the 4.0 cycle, and he’s done a fantastic job with the clustering, the JMX and the EJB implementation.
Tim: Is there a discontinuity here - supporting the full EJB spec must be a huge amount of effort, but in terms of usage, from what I gather from users at this Devcon, very few people are using EJB at the moment.
Edwin: Part of that is who’s here, which is the traditional Dreamweaver, ColdFusion, Flash web developer. They don’t use EJB much. If you go to Java One, for example, a lot more of those people are using EJB.
But yes, you’re exactly right. Even in most applications it’s not necessary. In some applications it is, and that’s where all the energy goes. This is for the higher complexity, more mission-critical applications. That’s what drives the J2EE market, the need for those use cases. That’s why most vendors spend less time focusing on ease of use, scripting, and easy management, and more time focused on high transaction rates and all of those things. The buying public has obviously said that’s what is most important.
Tim: I find EJB something of a nightmare, because it’s so hard to architect your application to take advantage of what is on offer. Is the solution in tools that can simplify the process, or does it need a revision or simplification of the EJB spec itself?
Edwin: It’s both. All the container services that EJB adds, in my opinion they push the envelope of the Java language. The reason you have so much complexity with Beans, the Bean instance, the Home instance, all these generated classes, deployment descriptors, is partly due to the fact that Java itself doesn’t express that kind of stuff. It has to be added in as patterns, either manually or with a tool.
In the end, it gets into model-driven design. If you can lay out your design just in terms of its patterns, then the implementation can be derived from that, either in the form of EJBs or Web Services or whatever. That’s what you want as a designer, as a modelling person. The tools chains just get much bigger and heavier.
Tim: Can you give me any clues as to where you’d like to take JRun in its next iteration?
Edwin: It’s pretty early. We’re looking at the next version of the J2EE spec, and looking very hard at what’s needed for rich clients. As you know, we released Flash Remoting as part of JRun, ColdFusion, and standalone. We’re looking at what we can do there, what the problems are, what problems people have putting the presentation layer on their J2EE applications. So JRun itself is focussed on being a good server.
Being a good server is something we can do, but so can everyone else. It’s a pretty well understood problem. But well-designed user interfaces? That’s uncharted territory. So every product team in the company is looking at problems like that. What people are doing to improve the user experience, to put better front-ends on things.
Tim: Personally I hope that JRun does well, because IBM shouldn’t run everything
Edwin: The market won’t let that happen. The market will always make sure there’s some competition, even when there’s a dominant vendor. We’re still running Apples. But implementing the J2EE spec is a commodity at this point. So you compete on service, support, performance, reliability, but it’s tough. So what we’re doing is saying, Macromedia is all about user experience, working out what means for JRun, and moving it in that direction.
Flash and ColdFusion futures
Tim: I’m interested in the use of Flash as a rich client. Of course Flash is horrible if you want to code any client-side logic into your application, better than it was, but still horrible. Have you thought of miniaturising JRun as say a J2ME engine that you could embed into Flash?
Edwin: That would be pretty interesting. One of the things that has enabled Flash to succeed is relentless focus on graphics and on small download. Right now it’s a 350K download. No instance of J2ME is that small. So there would be huge challenges on the distribution side. But it’s an interesting concept. It’s the client-server pendulum swinging. More logic on the client means more container services on the client, and it’s definitely an interesting concept.
Tim: An interesting aspect of ColdFusion is that it’s an example of declarative programming, which of course DreamWeaver also uses, not only with ColdFusion, but even with ASP.Net. Is that a deliberate strategy?
Edwin: Totally. That’s been ColdFusion’s approach from day one. Actually, to me declarative programming is like the way a makefile works, or the way an XSL stylesheet works, where there’s no implied control flow. What you’re doing is just declaring relationships. ColdFusion is only partially like that. But that is a great way to program. When you do it that way, the system can derive much better code for you. You’re working with more domain-specific terms for the problems you solve, instead of just generic code loops and assignments and things like that.
With ColdFusion, when new tags are necessary we add them in. For example we added a stylesheet tag. CFCs [ColdFusion Components] are new, and we’re definitely looking at what more we can do with CFCs. To me there’s a vast range of things we could do there, now that there is an object model built into the language.
ColdFusion vs JSP
Tim: Why would someone choose ColdFusion rather than just do JSP?
Edwin: ColdFusion is not as strongly typed as Java. It’s picked up by people who are interested in doing something other than programming. It’s a programming language but it’s basically trying to not be in your face and not require a lot of conceptual understanding of what’s going on. Even in jumping between JSP and ColdFusion, the extra use of colons, strict use of quotes on attributes, and the fact that you’re using Java instead of a scripting language, means you tend to have to think harder using Java.
If I’m picking between two environments, and I don’t mind thinking harder, and I’m thinking about power and standards, then JSP is a way to go. But if you’d really rather be running your business, or doing something other than coding, then ColdFusion is always appealing.
Copyright Tim Anderson 17th November 2002. All rights
reserved.
You are welcome to post links to this article. If you wish to print, distribute,
or copy all or part of it, please contact
me for permission, which may be subject to a fee.
Sign up to be notified of future articles
Macromedia Studio MX best buy: upgrade from 2 or more Macromedia products
Details here for (US) Studio
MX Windows and Studio
MX Mac
Details here for (UK) Studio
MX Windows and Studio
MX Mac
Latest books
On
ColdFusion MX and Other Web development topics