thejavajar

I have been a big fan of Spring’s PropertyPlaceholderConfigurer since 2006 when I could wire up a datasource bean, or any bean for that matter, with just some references to properties that I knew were going to be in place. A snippet from a Spring context file for example:

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${my.db.driver}"/>
<property name="url" value="${my.db.url}"/>
<property name="username" value="${my.db.username}"/>
<property name="password" value="${my.db.password}"/>
</bean>

Now, I can provide PropertyPlaceholderConfigurer with a .properties file location(s) or I could depend on the properties existing as part of the runtime, like when using JBoss Application Server’s property service. Then one day, I ran into a bit of an issue. Well, now I have an application with a properties file that has datasource connection information for each development region, DEV, TEST and PROD and the region is a ‘prefix’ on each property.

Something like…

DEV.my.db.driver
DEV.my.db.url
DEV.my.db.username
DEV.my.db.password

TEST.my.db.driver
TEST.my.db.url
TEST.my.db.username
TEST.my.db.password

… and so on. If you are packaging .properties files into your archive(.war, .jar, .ear), this does help your code be a bit more portable but I usually configure properties outside of an archive but we can’t always have our way. So, now we have a special class that reads the properties file and the region variable from SystemProperties as the region variable, SDLC_REGION, is set in each development region as a VM argument.

-DSDLC_REGION=DEV

And that works great. We can leave our Spring context alone and everything works like we need it to. But, I am always trying to reduce classes or utilities(.jar files) that are no longer needed in our applications. So, I took a look back into Spring 2.5′s PropertyPlaceholderConfigurer and low and behold, there is a better way to do things. Check it out. Here is my Spring context file now:

<context:property-placeholder location="classpath:db.properties"/>

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="${${SDLC_REGION}.my.db.driver}"/>
<property name="url" value="${${SDLC_REGION}.my.db.url}"/>
<property name="username" value="${${SDLC_REGION}.my.db.username}"/>
<property name="password" value="${${SDLC_REGION}.my.db.password}"/>
</bean>

Now, the VM argument, SDLC_REGION, exists in each environment and it can be a part of our PropertyPlaceholderConfigurer expression. We can now load the correct property for each development region from the packaged .properties file without depending on our utility class anymore. Really cool stuff and again, beautiful work from the people at SpringSource.

For the last ~1.5 years I have been working with IVR applications. The framework we use is Java based and we use an Eclipse based IDE with a nice drag and drop editor to create the application’s call flow. The IVR application is packaged into a .war or .ear file by the IDE and we deploy the application to a Web container like Tomcat. The IVR is then pointed at the application’s entry point URL. The core flow is mapped into Servlets and each request into the application generates VXML (Voice XML) that is interpreted by the actual IVR which is responsible for handling call control and communicating with the other telephony technologies.

I think there could/should be a way to use Groovy’s MarkupBuilder and most likely Gaelyk to create IVR applications with less ceremony than using the drag and drop editor. We can create static VXML very simply with Groovy’s MarkupBuilder:

import groovy.xml.MarkupBuilder

def writer = new StringWriter()
def vxml = new MarkupBuilder()

vxml.vxml {
    field (name:"color") {
        grammar ("red | green | blue")
        prompt (count: 1, "Say red, green or blue.")
        prompt (count: 2, "Please say red, green or blue.")
        noinput (count: 1) {
            prompt ("I didn't hear you." )
            reprompt ()
        }
        noinput (count: 2) {
            prompt ("Sorry, I still didn't hear you.")
            reprompt ()
        }
        nomatch (count: 1) {
            prompt ("I didn't understand you." )
            reprompt ()
        }
        nomatch (count: 2) {
            prompt ("Sorry, I still didn't understand you.")
            reprompt ()
        }
    }
}

writer.toString()

Here is the output of the above:

<vxml>
  <field name='color'>
    <grammar>red | green | blue</grammar>
    <prompt count='1'>Say red, green or blue.</prompt>
    <prompt count='2'>Please say red, green or blue.</prompt>
    <noinput count='1'>
      <prompt>I didn't hear you.</prompt>
      <reprompt />
    </noinput>
    <noinput count='2'>
      <prompt>Sorry, I still didn't hear you.</prompt>
      <reprompt />
    </noinput>
    <nomatch count='1'>
      <prompt>I didn't understand you.</prompt>
      <reprompt />
    </nomatch>
    <nomatch count='2'>
      <prompt>Sorry, I still didn't understand you.</prompt>
      <reprompt />
    </nomatch>
  </field>
</vxml>

Then, if a nice, simple DSL (Domain Specific Language) is designed for building IVR applications with Groovy, we can then simplify the craft of creating IVR applications. Plus, we would gain the productivity of using Groovy when calling Web services and databases to provide dynamic data for the application. Just a crazy thought.

I love browsing over to Groovy Console from time to time to check out scripts that have been recently published. It is a great place to learn Groovy or just have fun with Groovy without having to install anything. In the script below, I wanted to multiply two lists of Strings together so while playing around at the Groovy Console site I wrote:

java.util.ArrayList.metaClass.multiply = { e ->
    def list = new ArrayList()
    delegate.each { a ->
        e.each {
            list.add(a + it)
        }
    }
    list
}

x = ["k1", "k2", "k3"]
y = ["v1", "v2", "v3"]

x * y

Now, there may be a better way of handling this in Groovy, but I get the result I am expecting by implementing the multiply method for the ArrayList MetaClass in the top part of the script.

Then I create my lists, x and y, and multiply (*) them together. Nothing too crazy going on here but this demonstrates the power that Groovy can provide programmers with very little effort. Here is the result:

[k1v1, k1v2, k1v3, k2v1, k2v2, k2v3, k3v1, k3v2, k3v3]

Update:

A few more elegant solutions posted at the Groovy Console site.

Shorter version.*

java.util.ArrayList.metaClass.multiply = { e ->
delegate.collect { a -> e.collect { a + it } } .flatten()
}

x = ["k1", "k2", "k3"]
y = ["v1", "v2", "v3"]

x * y

Another version.*

java.util.ArrayList.metaClass.multiply = {
[delegate, it].combinations().collect { a -> a[0] + a[1] }
}

x = ["k1", "k2", "k3"]
y = ["v1", "v2", "v3"]

x * y

No MOP version.**

x = ["k1", "k2", "k3"]
y = ["v1", "v2", "v3"]
[x, y].combinations()*.join()

*Courtesy of Paul Holt.
**Courtesy of paulk_asert.

As we all have heard around the water cooler, Java is dead. Why is Java dead, I still have a job? Is it the language itself? Is it the Java Community Process (JCP)? Is it because Sun is no more? Is it the fragmentation of Java (IBM, Oracle, JBoss, Spring)? Is it because someone you follow posted it on Twitter? Is Java too complex? Is it the abundance of Java frameworks and tools? Is it the expensive conferences? Is it the books that are outdated before they are published? Is it because you are holding a hammer? Is it because the Oracle/Google patent lawsuit? It is because your IDE is still loading? Is it because your server is still down? Is it because I have a Rod Johnson bobble-head? It is because someone posted it to your local JUG mailing list? Is it because

public static void main(String[] args) {}

is just too much typing to actually start to get something done?

Has a language come along to take its place?

Groovy, C#, Ruby, PHP, Clojure, F#, Python, C++, R, Flex, VB.NET, Haskell, ActionScript, JavaScript, JavaFX, JRuby, Jython, etc. (Sorry if I left one of your favorites out.)

(inspired by real events on the Tampa JUG mailing list)