ToJava() - A ColdFusion User Defined Function For Complex Java Casting

ColdFusion is a typeless language; and, when we reside in the ColdFusion world, this is a beautiful feature that none of us really have to care about. But, from time to time, we have to dip down into the strongly-typed world of Java that lies just below the surface. At that point, going from lose ColdFusion data types to strict Java data types can be a bit of a headache. ColdFusion comes with a function - javaCast() - that is supposed to make this transition easier; and, most of the time it does. However, I find that javaCast() starts fall short in more complex conversions. As such, I wanted to try and make a more comprehensive Java-casting function - toJava() - that would perform a bit more magic behind the scenes.

Before we look at the toJava() function code, let's take a look at a situation in which the core javaCast() function fails to help us. If you've ever played around with Java's URL Class Loader, you've probably run into a situation where you have to build a typed-array of "java.net.URL" instances. While javaCast()'s documentation states that you can use Java classes to create arrays, I have found that this mostly fails:

As you can see here, we are creating a native ColdFusion array of JAR file paths. Then, we are using ColdFusion's native javaCast() function to try and convert that to a Java array of "java.net.URL" instances:

ColdFusion executes this command without raising any exceptions; however, when we run the above code, we get the following output:

As you can see, our Java array now contains one NULL (undefined) value rather than an instance of the "java.net.URL" class.

Now, let's run the same code; except, rather than using the native javaCast() function, we'll use my ColdFusion user defined function, toJava().

As you can see, the only difference in the two code blocks is the function that we are using to cast our lose ColdFusion data types to strict Java data types (NOTE: we are doing more than simply casting at this point - I discuss this further in my conclusion). This time, when we run the code, we get the following page output:

As you can see, our strongly typed Java array now contains an instance of the "java.net.URL" class. And, just to make sure that the "conversion" (ie. instantiation) worked properly, we can try to convert the URL instance back to a string:

This gives us the following output:

toString: file:/Sites/bennadel.com/testing/tojava/

Clearly, the "java.net.URL" instance was instantiated with the appropriate constructor arguments; and, as such, was able to be converted back to a string in a meaningful way.

OK, so what is the toJava() function doing? At its most core layer, it is using the native javaCast() function that ColdFusion provides. JavaCast() works great in many situations; so, if we can use it, we do. If, however, we are presented with a situation in which javaCast() is not a great choice, then we either use createObject() for single Java objects; or, we use the "java.lang.reflect.Array" class when we need to create an array of Java objects.

To keep the code as clean as possible, all but the most basic casting situations rely on being able to call the toJava() function recursively. While this adds some processing overhead, it removes a good deal of conditional logic and, I believe, makes the code easier to follow:

The first two arguments of the toJava() method - "type" and "data" - are required; the third argument - "initHint" - is not. This last argument is used when you want to provide casting information in the context of the Java class constructor. For example, in the above demo, I am creating instances of the Java class, "java.net.URL." When I do this, the toJava() function is actually invoking the constructor on the "java.net.URL" class. This constructor expects a strongly-typed string value. If you get into a situation where ColdFusion can't figure out how to translate your value into the required string, you can use this third argument to provide constructor-specific hinting:

Now, you might be looking at this toJava() function and think that it is totally off base; after all, instantiating and initializing a Java class instance is a completely different concept than that of casting one data type to another. And Yes, I agree entirely with that point of view; however, when you go from a typeless world to a typed world, I am not sure if that mindset necessarily needs to carry over. In any case, whether it is a good choice or bad choice to combine these two potentially divergent gestures, I believe that this function will prove to be very useful for those ColdFusion developers who need to reach into the Java layer from time to time.

Want to use code from this post? Check out the license.

Short link: https://bennadel.com/1980

Reader Comments

Bill Ryder Apr 5, 2012 at 9:12 AM

1 Comments

Thanks man. Helpful!

Ben Nadel Apr 5, 2012 at 10:07 AM

16,020 Comments

@Bill,

Thanks my man - glad you like it. Going from the loosely typed ColdFusion layer to the strongly typed Java layer can be irksome. Making the data conversions easier should help :)

Oh my chickens, this post is old!

Hit me up on Twitter if you want to discuss it further.