Today is a good day to code

An Open Java and it’s impact on ColdFusion

Posted: December 31st, 1969 | Author: | Filed under: Uncategorized | No Comments »

An Open Java and it's impact on ColdFusion

Picture of Irv Owens Web DeveloperI have been complaining for a while about the need for ColdFusion to run on Java, not because I don't think that the performance of Java is adequate, or that there are a vast many things that can't be done within the JRE, but because of idiosyncracies that could be remedied with access to the source. After building applications for a while, one begins to appreciate the difficulty of trying to base an application on a framework without having full understanding of how and why it does the things it does. For applications to be developed to their potential, it would seem to require that the developers of an application would have a virtual field day if they could bundle their own version of the Java Runtime with their application server.

I understand why Sun would take issue with this. If Java became huge, larger than it was, and every developer were to have free reign to adjust the runtime, it would lead to very stable and quick Java applications, but on the other hand it would also lead to installing as many runtimes on a person's computer as there were applications. For an engineer, this amount of waste would be un-nerving, not to mention the possibility of poorly written runtimes that could sully the reputation of Java. Sun has been right in controlling the source to Java and thus ensuring the stability of the runtime.

That being said, if there were to be an agreed upon core to the runtime, with only open source code added on, the result would be a unified runtime with plugs for developers to build add-ons for integration with their applications. This would allow developers to build compatible closed source Java applications with a common runtime. Problem solved, and this is the way it seems that Sun is moving, despite the pressure from IBM.

ColdFusion, running on top of Java has strangeness. Probably the most recently annoying strangeness is the problem of the query-of-queries. The functionality provided by the query-of-queries and the ability to create query objects in ColdFusion is indespensible for developers looking for easy ways to structure and access data across pages. It is, however, buggy. One of the bugs I have come across is the issue that Java, being typed the way it is, insists upon casting some the fields in my custom query object to the double type, even though I have explicitly included quotes in the “QuerySetCell” command. When I try to query the existing custom query object, ColdFusion tells me that it basically can't use a string to query a double typed object. Another strange one was that it kept telling me that my field name was an incorrect operator. It was a field name! Fortunately I happened across a good post that told me to enclose the field names in brackets to make sure ColdFusion would not, in the WHERE clause, confuse them for commands or system words. This seems to have worked, but I am still working through the above issue.

Screaming at it doesn't help, the issue is an underlying Java issue I am sure, and whatever the ColdFusion team will have to do to fix it will have to be a workaround since they can't untype Java. What if, however they could, what if they could customize the JRE for ColdFusion and the way it looks at objects. The benefits would be enormous. They could introduce closed source database drivers that could have the potential to blow away their JDBC counterparts by integrating system native elements, the possibilities would be limitless. The developer would have the ability to decide how much of the common runtime they wanted to include, or leave out. They could revise some of the code they felt was inappropriate, or could build in system native portions where it could improve performance or scalability. In other words, they could have as much of Java as they wanted without the parts the didn't want. Opening Java will save it, but Sun is doing the right thing by opening it slowly and with solid partners like Borland and IBM to influence the development of OSS Java. As long as Adobe doesn't do anything too crazy, the future of ColdFusion is even brighter with an open Java.

Oh yeah, and for the Windows Server users among us, porting ColdFusion to .net so that it will run on the CLR would be only marginally difficult based on C#'s similarity to Java's syntax. The benefit to this is that any enhancements Microsoft made to the CLR would immediately be reflected in ColdFusion. I'd bet that Microsoft's DB support is greatly improved over the simple JDBC that is included with Java, I could be wrong and I'd like to see some benchmarks, but from use I have seen that ODBC spanks JDBC every day of the week even if it is simpler.