A ColdFusion IDE feature request: tools for creating Java classes
But not everyone agrees on what the solution to this issue should be. Some folks believe that Adobe should try to improve object generation performance even more, building on the improvements that came with ColdFusion 8. Others feel certain that ColdFusion will always pale in comparison to Java when it comes to object generation and that any enterprise-level ColdFusion application should use pure Java classes on the back end. A few folks at cf.Objective() even advocated integrating ActionScript 3 (the strongly-typed programming language behind Flex) into ColdFusion for use in building objects.
Personally, I would love to see a big improvement in object performance in the next version of ColdFusion 9, but I strongly suspect that equivalent objects written in pure Java classes will still be significantly better in terms of performance despite Adobe's best efforts.
If we accept that as the most likely outcome, then the issue becomes how to get ColdFusion developers without any Java background (like myself) to code objects in Java?
I think one way of accomplishing that is for Adobe to create a ColdFusion IDE that provides ColdFusion developers with an easy means to create Java classes and use those Java classes for the model in their applications. It could provide a wizard similar to the CFC wizard tool in CFEclipse that either generates the .java file based on a database table or lets the developer manually define properties and methods for the class. It could also provide a means of generating the Java class files based on an XML configuration file so existing code generators could be modified to work with this IDE feature.
Of course, creating the .java files is only the first step. The IDE should also be able to introspect any .java file and display all of the information a developer would need to interact with that resulting class (properties, methods, data types, etc.) If the developer needs to make changes to the class, they could either edit the .java file directly in a normal IDE editor window (with syntax checking), or via an editing dialog box that lets the developer make changes to the configuration of a method and the statements within the method without having to worry about aspects of the Java syntax involved in describing the method. The IDE would also take care of compiling the .java file to a class every time it is updated and reporting back any compilation errors.
Like I said, I have no Java programming background, so maybe this idea is more than a bit of a stretch. There are also probably other issues that would need to be addressed (like how to manage the dependencies between the Java classes), but I'm betting cleverer folks than I could figure out a way to make it work. Even if the tools for creating Java classes were limited in what they could do, allowing ColdFusion developers to generate their own .java files and Java classes using familiar terms and concepts and then see the results could shorten the Java learning process.
ColdFusion has a long tradition of making it easy for developers to perform certain tasks and operations. When we talk about that tradition, we tend to narrow our focus on the capabilities of the CFML language. We tend to forget that the ColdFusion server software makes our lives easy as well, letting us configure datasources, security features, and gateway processes without having to deal with those issues in our programming code. It's the entire ColdFusion package, as a whole, that makes developing in ColdFusion easier than developing in other languages.
If Adobe develops a ColdFusion IDE, that IDE should also be designed--optimized, in fact--to make developing in ColdFusion easy, regardless of the developer's skill level. So I say if our OO ColdFusion developers need to be able to create their objects in Java, that IDE should help them do that.
I wasn't at cfObjective so not sure if this came up in the same discussion, but the iterating business objects Peter Bell advocates would go a long way to solving some of these problems. Having an object with instance variables that are arrays instead of the inverse would probably be a solution in many cases.
I haven't had a chance to dig into Peter's IBOs yet, but my understanding is that while IBOs can take the place of object collections in ColdFusion, they won't help you if you then need to make a Flex version of your application, and being able to take your existing model as is and leverage it with other UI technologies is becoming more and more important to those folks building OO ColdFusion applications.
Once of the biggest performance issues is the fundamental approach CF takes to generating Java classes - creating a class for every single method in an object. I would imagine that would be a lot more of a problem than the fact that they have to do a bunch of casting behind the scenes to handle the implicit variable conversions that CF supports.
Personally I use the IBO and it makes object creation costs irrelevant - even for large data sets. As for Flex, I'm working on a simple script to allow an IBO to return an array of as3 objects. There is a method using specially named structs which (I believe) is what CF uses under the hood to do its CFC to as3 conversions using remote objects. I haven't had a play with it yet, but it promises to give all of the benefits of remote objects without the object instantiation costs of using CFC's.
The real problem with allowing ColdFusion developers to write Java in the IDE is that we'd have to write Java in the IDE. We wuld have to type all of our variables, cast for type conversions, we wouldn't be able to mix in functionality as easily, we'd need to use method overloading (multiple methods with different type signatures to handle different typed arguments, etc.). We'd have to learn about generics and use interfaces so that our objects implemented the right types to work with each other.
It is one possible approach, but I don't think it is at the core of the CF mission which is to make hard things easy. Personally I'll just stick with my IBO as for me it is "problem solved"!