This year, Brian Rinaldi invited me to speak at RIAUnleashed. By way of background: RIAUnleashed is a 2-day conference, held in Boston, founded by Brian Rinaldi, with a speaker and topic list as diverse as the fair city in which it’s held. As its name implies, its focus is “RIA” – Rich Internet Applications, though that concept is now so broad that it perhaps defies definition. This year, you’ll see Flex, AIR, Android, LiveCycle, ColdFusion, and even something called “Blitting” which, as a server-side dude, I’m both proud and ashamed to say is something that gets a WTF? from yours truly.

Check out the Agenda. It is, in a word, Fun! But that’s not what I want to talk about. This isn’t a post about “Why you should attend RIAUnleashed”. If the topics don’t interest you, fair enough. I want to get more personal.

This is my story

I know a little bit about education

I began my professional life as an English teacher. I graduated from IUP in 1996 with a degree in English Education. I taught high school English from January 1997 to June 2000. My heart was, and to some degree a part still is, in education. I left this hallowed profession for the most pedestrian of reasons (money. duh.). But I was good. I think. Anyways, as a student of teaching, and as a teacher, I learned much, the most germane here being this: when you give people ownership, they tend to respond in ways you could not predict. This is most certainly true of young people, in my experience as both a teacher and a parent. The difference between “ye shall do this”, and “what are you interested in? Now do it. Make us proud” is nebulous and enormous. It’s hard to measure. I shan’t attempt to do so here. Thus, this is yet another in the annals of subjective wish-wash. I’m cool with that.

Upon the approaching of the first RIAUnleashed, Brian asked me if I’d speak at his conference. I was honored, to be sure, but occupational obligations prevailed (never again, btw… the “deadline” I needed to meet never came to pass). Lesson learned.

This year, Brian asked again. I graciously accepted and asked what he’d like me to speak on. His response:

What do you want to talk about?

My gut tells me that this is probably one of the riskiest responses a conference organizer could propose. Think about it: you’re bootstrapped. You have no mega backing. You are funding this conference on attendance and the goodwill of some some supporting sponsors, but above all, asses in seats pay the bills. By all rights, Brian should be “reading the tea leaves”, asking of the world: “what do you, dear World, want to know about?” and then he’d enlist speakers to present on those topics.

Instead, he asks people, “what do you want to talk about?”. He chose speakers first, and the topics came later. This I admire.

Why this matters to me

While I have a J-Lo sized booty, I’m no prima donna. I’m generally known for being part of the unit testing / TDD fringe of the CFML community. I typically propose conference topics in those areas because they’re “safe” for me, and frankly because there’s not much competition.

But I’ve given those presentations, and I don’t like to talk about them more than once. Part of my fake motivation as a speaker is that I know if I’m talking about something in front of an audience, I’m probably only going to get one shot at it. I don’t recycle topics. So lately, while I’m known for one thing, my interests have gone in other directions. I’ve been spending more of my free time on datastores, parallel computing, and other investigations into “high scalability” applications.

In May, when I joined Booz Allen Hamilton, I was given the opportunity to investigate NoSQL datastores for an application, and I settled on MongoDB for a POC application. A love affair was born, and I haven’t let go.

So recently, when Brian asked me if I’d speak, I asked him if he’d accept “MongoDB for CFML developers” as a topic. He didn’t flinch, and I’ll be there in November, talking about my current passion.

How is this any different from what I’ve done in the past?

As I said, this is my own story. I’m not writing from the perspective of a business owner or conference organizer or, even, as a “smart guy”. This is a dude who will stand at the front of a room for an hour.

Several times recently, I decided to stop submitting topics that would increase my chances of acceptance, and instead submitted on only the things I cared most deeply about. By my count, I’m at about a 33% accept rate with that approach, not including RIAUnleashed. That’s completely cool! Because for the topics I’m presenting on, I feel as energized as I’ve ever been. I’m grateful for the opportunity to speak on things that matter to me, and I hope that translates into meaningful presentations for the folks gracious enough to attend.

So, to Brian: thank you for this honor. I’m excited to be in Boston for RIAUnleashed, both as a speaker and attendee of other fantastic sessions!

MXUnit 2.0.1 is now out in the wild. It fixes some bugs and adds some enhancements. Read all about it in the Release Notes.

Enjoy!

--marc

On Twitter, Jason Dean asked: “Is there a way for me to create an ArrayList<String> in ColdFusion for passing into a Java constructor?”

I responded saying I thought he should only need to create a regular old ArrayList and that the jvm should accept it, even though there’s technically no way to do “Generics” in java.

Summary

Your CFML code needn’t care if a java method expects a Collection of  Generic types. You can create objects of the “raw” type and pass those. However, If your collection object contains objects of a type that the original programmer didn’t expect, your code will most likely fail. Thus, consider the Generic type declaration as an instruction to you, the programmer, instead of an instruction to the compiler.

If you want to know why, read further.

If you’d like to play along, you can get all the code here: http://github.com/marcesher/HybridCFJava

What are Generics?

What he’s talking about are Java Generics. That’s the little angle bracket thing in there.

Given this code:

public String echoGenericStringList(List<String> list){
        return list.toString();
}

And then some driver code:

ArrayList list1 = new ArrayList();
list1.add("Hi");
list1.add("Hi2");

ArrayList<String> list2 = new ArrayList<String>();
list2.add("G: Hi");
list2.add("G: Hi2");

System.out.println(gm.echoGenericStringList(  list1   ));
System.out.println(gm.echoGenericStringList(  list2   ));

1) The echoGenericStringList method declares an input of type List. Additionally, it expects that list to contain only Strings.

2) The first ArrayList – list1 – is a “raw” ArrayList. I’ve declared no additional type requirements on it. It can contain any types: Strings, Integers, Foos, Bars, Unicorns. Whatever.

3) The second ArrayList – list2 – is a a “typed” ArrayList. It instructs the compiler to fail if any attempt is made to add something to the list that isn’t a String. Thus, list2.add(“one”) is fine, but list2.add(1) is not.

Raw vs Generic; Compile-time vs. Runtime

Neither of these last two lines will fail compilation. The second one is obvious: the method declares an input of type List<String> and gets it. But the first one… why doesn’t it fail? It’s getting a “raw” list, not a generic list.

The answer is: Because that’s how generics work.  The compiler will issue a warning, but it will not fail. A method declaring inputs with Generic types must accept inputs of raw types. The downside is that when using raw types, you lose the type safety which Generic types confer.

The key to understanding this behavior is this: Currently, generics are a compile-time type check. The typing of that list: ArrayList<String>, is erased upon compilation, and during run-time no check is made. That’s why, for example, the compiler would not complain if you added an Integer to list1 above and passed it to echoGenericStringList(List<String> list), but it would complain if you attempted to add an Integer to list 2 – since that list has been declared to only accept Strings.

Importantly, if you were to try this, the compiler does not complain at the line of the actual method, the public String echoGenericStringList(List<String> list), but at the point where you attempt to create a List that does not honor the contract of that list’s declaration. See this screenshot:

Notice that the compilation failure – the line of code with the red x beside it – happens at list2.add(1), not on the method itself.

If none of this makes sense, well, that’s expected if you don’t know Java. The bottom line here is that Generics are inspected at compile time and erased prior to runtime. The contents of the Generic Collection only matter at compile time; at runtime, you’re on your own.

This compile-time check doesn’t eliminate the possibility of type errors at runtime… but it greatly mitigates it. If you’re a CF developer, you probably don’t care at all about compile time type checks, which brings us to…

What does this mean for CFML developers?

Quite simply, it means that we can basically ignore generics in our CFML and treat methods that expect generic collections as if it expected a “raw” type collection. So, for us, a method declared thusly:

public String foo(List<String> list)

is the same as

public String foo(List list)

The reason is that by the time our CFML calls that foo() method from some Java class, that java code has already been compiled. The byte code does not have any notion of Genrics at this point. So when we create a non-Generic list in our CFML, the JVM will gladly accept it since it’s the same as if we were passing in a raw list, as in the example above. Java developers may bemoan the fact that Generics are erased at runtime, but we CFML developers can take advantage of that fact.

Thus, this CFML works fine:

<h2>Using Java Generics</h2>
<cfset genericMethods = loader.create("generics.GenericMethods")>
<cfoutput>

        #genericMethods.echo("hello")#
        <br>
        
        <cfset list = createObject("java", "java.util.ArrayList")>
        <cfset list.add("hi")>
        <cfset list.add("boo")>
        
        <cfset ilist = createObject("java", "java.util.ArrayList")>
        <cfset ilist.add(1)>
        <cfset ilist.add(2)>
        
        
        
        Echo a list: #genericMethods.echoList(list)#
        <br>
        Same list, passed to method expecting ArrayList<String>: #genericMethods.echoGenericStringList(list)#
        <br>
        New List with only ints, passed to method expecting ArrayList<Integer>: #genericMethods.echoGenericIntegerList(ilist)#
        <br>
        <cfset iList.add("foo")>
        Method expecting int list gladly takes list with non-ints: #genericMethods.echoGenericIntegerList(iList)#

</cfoutput>