In ColdFusion MX, you can create a Java object by calling the handy CreateObject() function.

<CFSET myObj = CreateObject("java", "java.util.Hashtable")>

Suppose you have the following Java class:

class Person {
    private String name;

    public void setName(String n) {
       this.name = n;
    }
}

Now, let’s create an instance in ColdFusion and set a name:

<CFSET somebodySpecial = CreateObject("java", "Person")>
<CFSET somebodySpecial.setName("Chuck")>

Cool, but what happens if you pass an argument that isn’t a string:

<CFSET somebodySpecial.setName(123)>

coldfusion.runtime.java.MethodSelectionException:
    The selected method setName was not found.

Whoops! ColdFusion wasn’t able to find a method of Person with a signature of “public void setName(int)“. What you need to do is cast the arguments to the correct datatype. For this example, you could do something like this:

<CFSET somebodySpecial.setName(ToString(123))>

The problem is what if you need to call methods that use other data types such as int, double, or boolean. ToString() won’t cut it. Instead use ColdFusion’s JavaCast() function:

JavaCast(type, variable)

type        "boolean"
            "int"
            "long"
            "float"
            "double"
            "String"

variable    A ColdFusion variable that holds a scalar or string type

So, the correct way is:

<CFSET somebodySpecial.setName(JavaCast("String", 123))>
<CFSET somebodySpecial.setName(JavaCast("String", "Chuck"))>

No more MethodSelectionExceptions!

There are circumstances where you may need to have more than one version of Java installed, but how do you switch between them?

Execute the following command to list the installed JVMs:

sudo update-alternatives --config java

Which will output something similar to the following:

There are 3 alternatives which provide `java'.

  Selection    Alternative
-----------------------------------------------
          1    /usr/bin/gij-wrapper-4.1
*         2    /usr/lib/jvm/java-1.5.0-sun/jre/bin/java
 +        3    /usr/lib/j2se/1.4/bin/java

Press enter to keep the default[*], or type selection number:

Simply enter the number for the JVM to use. The * shows the current selected JVM.

Just the other day I stumbled across some weird syntax in some Java code that I’ve never seen or read about. I started to research it and discovered it’s called an anonymous inner class. Basically, it’s defining a one-time use object.

The code I was looking at is used to establish a connection to an SSL website. It just so happens that in my scenario, the website was using a self-signed certificate and in order for the HttpsURLConnection to connect, I needed to define a HostnameVerifier to force the hostname to be valid. Here’s the static function:

public static void setDefaultHostnameVerifier(HostnameVerifier v)

Now I need to create an object that implements the HostnameVerifier interface who’s definition looks like this:

public interface HostnameVerifier {
    boolean verify(String hostname, SSLSession session)
};

So, if I were to do this the old way, I would need to do this:

public class MyHostnameVerifier implements HostnameVerifier {
    public boolean verify(String hostname, SSLSession session) {
        return true;
    }
};

And then in my code call:

MyHostnameVerifier mhv = new MyHostnameVerifier();
HttpsURLConnection.setDefaultHostnameVerifier(mhv);

Yuck! Why would I want to create MyHostnameVerifier if I’m only going to be using it once? That’s where anonymous inner classes come in.

HttpsURLConnection.setDefaultHostnameVerifier(
    new HostnameVerifier() {
        public boolean verify(String urlHostName, SSLSession session) {
            return true;
        }
    }
);

This is much cleaner. What if we wanted our verifier to check a Hashtable to see if a specific host is blocked. In order for our anonymous inner class to be able to access variables outside its scope, the variables must be final.

final Hashtable<String,String> blockedHosts = new Hashtable<String,String>();
blockedHosts.put("10.0.0.1", "10.0.0.1");
blockedHosts.put("10.0.0.2", "10.0.0.2");
blockedHosts.put("10.0.0.3", "10.0.0.3");

HttpsURLConnection.setDefaultHostnameVerifier(
    new HostnameVerifier() {
        public boolean verify(String urlHostName, SSLSession session) {
            return !blockedHosts.containsKey(urlHostName);
        }
    }
);

You need to be careful when you final your outer variables. The classic example is a outer variable used to keep track of a count. If you simple do final int count = 0;, you will not be able to update the count. However, if count was an array, the array is final, but the elements within are not:

final int[] count = new int[1];

Then you would just access count[0] every time you wanted to change its value.

As you can see, Java anonymous inner classes are fun!

A PFX (Personal inFormation eXchange) file is a PKCS #12 certificate that can contain both public and private keys. Windows loves this format, but if we want to use them from a Java program, we will need to convert them to a Java keystore.

Before we begin, make sure you have the Java runtime installed. I’m using Java 1.5.0_07, but 1.6 may work. I doubt 1.4 or below will work.

To make this easy, we are going to leverage a utility class that is bundled with Jetty, a free Java web server. Download the latest stable version from their site, which at the time is version 6.1.1.

Extract the zip file to a folder, then open a terminal and change into that folder and execute the following:

$ java -classpath lib/jetty-6.1.1.jar org.mortbay.jetty.security.PKCS12Import

You should get a message that looks like this:

usage: java PKCS12Import {pkcs12file} [newjksfile]

If you don’t see this exact message, then make sure you are using a valid Java and Jetty version and make sure you are in the Jetty folder. Moving on.

Now, that things work, you can actually pass the path of the PFX file and the keystore to create. You will be prompted for the passwords for both files.

$ java -classpath lib/jetty-6.1.1.jar org.mortbay.jetty.security.PKCS12Import
         MyCert.pfx MyCert.jks
Enter input keystore passphrase: ******
Enter output keystore passphrase: ******

When it is all said and done, you should be looking at a shiny new Java keystore file. Verify the keystore by executing the following and entering the password you entered above:

$ keytool -list -keystore MyCert.jks -v

Enter keystore password:  ******

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: 29d1a9e13ca529ef1a32b1ea135b713_5a537e12-9c8e-833f-bb76-30ab870dd21
Creation date: Jan 1, 2007
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=XXXX, OU=IT, O=XXXX, L=XXXX, ST=XXXX, C=XXXX, EMAILADDRESS=XXXX
Issuer: CN=XXXX, O=IT, L=XXXX, ST=XXXX, C=XXXX, EMAILADDRESS=XXXX
Serial number: a0032c317ba3200000e1
Valid from: Mon Jan 1 00:00:00 CDT 2007 until: Tue Jan 1 00:00:00 CDT 2008
Certificate fingerprints:
         MD5:  B1:63:6A:2C:2E:97:A4:33:E9:61:98:01:CA:0B:74:91
         SHA1: 61:98:01:04:7D:33:6C:2E:97:A4:D2:C7:61:61:B1:63:6A:2C:2E:97

Your output may vary, but you should have a valid Java keystore in the end. You can use the keytool tool to merge this keystore into another existing keystore, but I’ll leave that for another day.