If you missed this year's CFUN conference (June 26-27), you missed a lot. In addition to the great time spent meeting and talking with other ColdFusion programmers, Ben Forta gave a keynote demo of the next version of ColdFusion, code-named "Blackstone".

I haven't been this excited about the release of a version of ColdFusion in quite some time. Blackstone has new features for using Flash to produce very sophisticated, very user-friendly forms with advanced features such as tabs and accordions. It adds excellent support for producing PDF files from native ColdFusion code, and it introduces a new, very powerful report writer. And of course, it does all this with the trademark ease of programming for which we've come to depend on ColdFusion. It will, in short, make you a coding hero.

This makes ColdFusion the best presentation language available and this is important - very important - because to the users, the user interface is the application. I have been puzzling for some time over the question of where ColdFusion fits in the enterprise space increasingly dominated by the J2EE and .NET platforms, and with Ben's presentation I think I see how perfect a marriage ColdFusion is with Java.

Java is the proverbial 800-pound gorilla in the enterprise computing space. It runs on virtually every processor (given its "write once; run anywhere" ability) and is used for everything from running Mars rovers to cellphones to gas station pumps. But Java is primarily a server-side language, which is where it excels. Adoption of Java applets on the other hand, has slowed to a crawl.

ColdFusion - particularly the Blackstone version - excels at providing the presentation layer, but is much weaker than Java on the server side, where it lacks such Java features as constructors, interfaces, abstract classes, overloading, and a null object - all undergirded by Java's strong data typing that virtually eliminates runtime exceptions.

In this article, I want to demonstrate how ColdFusion and Java can work beautifully together. First, though, I must apologize for the ColdFusion presentation layer shown here. Due to space considerations, my presentation code is going to be woefully simple, but I hope it will show how easily ColdFusion can work with Java.

First, let's look at the Java code. I've used several of Java's features that ColdFusion lacks to create a more robust "domain model." (A domain model is a scale model code representation of the "domain" under study.) I start with a Pet interface. In Java, an interface provides the specification for a data type (including methods), but provides no implementation. Here's the code:

package pettingZoo;

public interface Pet {
	public String getName();	
}

Now any class that wishes to can declare itself to be of type Pet. The requirement, set forth in the Pet interface, is that all "implementing classes" must implement a getName method that returns a string. The Java compiler will ensure that all implementing classes will be well behaved.

Next, I'll create an abstract class, Animal, that won't be used to create actual Animal objects, but is meant to be used by subclasses, where it will provide a base of inherited code:

package pettingZoo;

public abstract class Animal {
	private String food = null;
	
	public Animal(String food){
		setFood(food);
	}
	
	public String eat(){
		return "Thanks for the " + getFood();
	}
	
	public String getFood(){
		return this.food;
	}
	private void setFood(String food){
		this.food = food;
	}	
}

Two more Java classes, Dog and Cat, will extend Animal while implementing the Pet interface by providing a getName method:

package pettingZoo;

public class Dog extends Animal implements Pet {
	private String name = null;
	
	public Dog(String name){
		super("kibbles and bits");
		setName(name);
	}

	public String getName() {
		return this.name;
	}
	private void setName(String name){
		this.name = name;
	}
}
__________________________________________
package pettingZoo;

public class Cat extends Animal implements Pet{
	private String name = null;
	
	public Cat(String name){
		super("fish nibblies");
		setName(name);
	}
	
	public String getName(){
		return this.name;
	}
	public void setName(String name){
		this.name = name;
	}
}

Next, we have a RoboDog class that, while not extending Animal, implements Pet:

package pettingZoo;

public class RoboDog implements Pet{
	private String name = null;
	
	public RoboDog(String name){
		setName(name);
	}
	
	public String getName(){
		return this.name;
	}
	private void setName(String name){
		this.name = name;
	}
}

Our last Java class, PettingZoo, provides a way of modeling a very simple petting zoo. It has a method that allows us to add a pet to the collection and another method to return all of the pets:

package pettingZoo;

import java.util.*;

public class PettingZoo {
	private List pets = null;
	
	public PettingZoo(){
		setPets(new ArrayList());
	}
	
	public void addPet(Pet pet){
		getPets().add(pet);
	}
	
	public List getPets(){
		return this.pets;
	}
	private void setPets(List pets){
		this.pets = pets;
	}
}

"But wait!" you say. "I don't understand all that Java stuff."

Well, that's the whole point. You don't need to. You're going to make use of a domain model written in Java to produce ColdFusion applications. The Java classes don't do anything by themselves: they just wait to be called upon. All you need to do is understand the API (the Application Programming Interface) for the classes you'll be using. In simpler terms, you need only understand what methods are available to call and what these will return. It's the same process you use when calling a built-in ColdFusion function (though with a different syntax). Java has a wonderful tool called "Javadoc" that automatically produces the API documentation you'll need from the underlying Java code.

With the Java out of the way, we can get down to our ColdFusion application code. First, I created an Application.cfm file:

<!--- set up application framework --->
<cfapplication name="CFandJavaDemo" />

<!--- create an application-scoped Java class, Petting Zoo --->
<cfif NOT IsDefined('Application.pettingZoo')>
	<cfset Application.pettingZoo = CreateObject('java',
	'pettingZoo.PettingZoo').init() />
</cfif>

We're creating an object called pettingZoo from the Java class, PettingZoo, and placing it in the application scope. Now, for a main menu from MainMenu.cfm:

<h1>Main Menu</h1>

<p><a href="NewPetForm.cfm">Create</a> a new pet to add to the Petting
Zoo</p>

<p>Ask each of the pets in the zoo for their <a
href="PetGreeter.cfm">name</a></p>

It looks like that shown in Figure 1. If the user elects to create a new pet, the NewPetForm page is displayed:

<h2>New Pet Form</h2>
<p>What kind of pet would you like to add to the Petting Zoo?
<form action="ProcessNewPetForm.cfm" method="post">
<ul>
	<li><input type="Radio" name="petClass" value="Dog" checked> Dog</li>
	<li><input type="Radio" name="petClass" value="Cat"> Cat</li>
	<li><input type="Radio" name="petClass" value="RoboDog"> Robot Dog</li> 
</ul>
</p>
<p>What would you like to name them? <input type="Text" name="petName"></p>
<p><input type="Submit" value="ok "></p>
</form>

The code produces the page shown in Figure 2: This forms asks the user the type of pet to be created and the new pet's name. When the form is submitted, ProcessNewPetForm is run:

<cfset newPet = CreateObject('java',
'pettingZoo.#form.petClass#').init(form.petName) />
<cfset Application.pettingZoo.addPet(newPet) />
<cflocation url="MainMenu.cfm" />

It's very short, letting Java do the heavy lifting of creating Pet objects and storing them in the petting zoo's collection. It then returns to the main menu.

If the user chooses to ask each of the pets for their name, PetGreeter is called:

<!--- Ask each pet in the pettingZoo for their name --->
<cfset pets = Application.pettingZoo.getPets() />
<cfloop from="1" to="#ArrayLen(pets)#" index="i">
	<cfoutput>
   	#pets[i].getName()#<br />
   </cfoutput>
</cfloop>

PetGreeter loops over the pets returned by Java's PetZoo object, asking each pet - each Java Pet object, that is - for its name (see Figure 3).

With code understandable by any ColdFusion programmer, we've created a ColdFusion application that ties into a Java domain model.

The possibilities offered by the marriage of Java and ColdFusion are tremendous. It allows enterprises to call on the strength of each language and allows for the separation of the very different skills of server-side programming and presentation layer programming.

When Blackstone is released, ColdFusion programmers will have an entirely new set of features and tools to work with, empowering them to produce richly interactive applications while integrating with Java enterprise domain models. It promises to be a lovely wedding - and we're all invited to the party.