thejavajar

The final day of the Greater Florida Software Symposium (NFJS) ended a bit short for me because I had some plans for the afternoon, but I was able to attend 2 great sessions. I attend the Aspect Oriented Programming with Spring AOP and Compile Time and Runtime Metaprogramming with Groovy which were both presented by Jeff Brown of SpringSource. Aspect Oriented programming is an interesting concept and sometimes, when applied to Java, entices developers to throw AOP at as many problems as possible. The session touched on not only the technical side of Spring AOP but, the practicality of using Spring AOP for logging, transactions and security. Complimentary to AOP, the session on metaprogramming with Groovy went into the details of how Groovy supports the addition of methods and properties on any class during compilation or runtime. I really enjoy Groovy’s metaprogramming features and have run into quite a few cases where it would solve many, many problems when writing Java.

Overall, I think the Greater Florida Software Symposium (NFJS) was successful here in Tampa. I look forward to the return of the event next year and I hope that attendees will share their experiences with colleagues. More information on NFJS events can be found here and between now and next year’s event, come out and participate in monthly sessions at the Tampa JUG.

Started off day 2 with Test Driven Design with Neal Ford. It was a great session and I left feeling guilty about some of the code I have written in the past. Seriously. TDD can help you design and write better code and he proved it. Then I wandered over to Jeff Brown’s session, Enterprise Web Applications with Grails. It was a pretty good overview of what Grails has to offer. I am pretty familiar with Grails, but I did pick up on a few new things that I have never used or even seen before. REST is a pretty popular topic and Ken Sipe’s session, Spring 3 into REST, went into pretty good detail on how to get things done with Spring, specifically Spring MVC. Then I visited Jeff Brown again to check out his session, Polyglot Web Programming with Grails. The expandability of Grails as a platform is pretty amazing. I will probably have to put together another post on the topic, but first I need to look into Clojure a bit. Ended the day with a BOF session on alternative languages on the JVM. It is great to sit around and talk shop with the presenters of NFJS. Day 3 is around the corner.

First, it is great to have a major conference in my backyard. Second, when/if given the chance to attend a NFJS event, don’t ignore the opportunity. Today I attended Implementing Evolutionary Architecture with Neal Ford. It was a great presentation that hovered around REST, HTTP, XML and solving common enterprise architecture problems with simple solutions. I learned quite a bit, Neal Ford knows what is going on. During The Art of Messaging session with Mark Richards I thought of some ways I can leverage messaging at work. I really need to look at Spring JMS again. Mark’s session reminded me of the power of messaging. The last session I attended, The Busy Java Developer’s Guide to Advanced Collections with Ted Neward, was the best core Java presentation I have seen in a really long time. I was blown away by some things that I have overlooked for quite some time. Neal Ford closed the evening with a great keynote presentation that focused on the future of our craft, software development. He didn’t break out a crystal ball, but he made some great points about how we interpret history and how we can be blind-sided by what is already here. Alright, I am off to sleep. I have to be fresh for day 2.

The other day, while working on a Java project, I realized that I could implement an application requirement quite quickly by extending a current domain object and adding an attribute. This is an enterprise wide, industry standard domain object model so I couldn’t just add the attribute to the domain object without cutting through some red tape. Plus, it was an attribute that I needed for my application and it would most likely have no use in other projects. So, I had something like this:

public class Policy {

	private String policyNumber;
	private Double value;
	private Double interestRate;

	/* getters and setters */
        ....
}

Then to get things done, I went ahead and created:

public class MyPolicy extends Policy {

	private String myNewProperty;
	private Policy p;

	public MyPolicy(Policy policy) {
		this.p = policy;
	}

	/* getters and setters */
        ....
}

Now, I could fulfill the requirement with ease because I now had a Policy object with the extra attribute I needed, myNewProperty, all in the MyPolicy object. I could now handle the Policy returned from the Web service call and pass it into the MyPolicy constructor, do some work to create an instance of MyPolicy with a Policy object, derive the value of myNewProperty and then send it on to a view for example. Nice, I think that will work for my application.

Later, I thought about how nice it would have been if the Policy object was implemented with Groovy. Then I could take advantage of Groovy’s metaprogramming features like propertyMissing. When I have propertyMissing in my language arsenal, I can create the Policy object like so:

class Policy {

	def properties = Collections.synchronizedMap([:])

	String policyNumber
	Double value
	Double interestRate

	def propertyMissing(String name, value)  { properties[name] = value }

	def propertyMissing(String name) { properties[name] }
}

In the implementation above, the propertyMissing(String name, value) method is called when trying to set a value, myNewProperty, that doesn’t exist in the Policy object. The propertyMissing(String name) method is called when trying to get a property, myNewProperty, that doesn’t exist in the Policy object. By default, the propertyMissing(String name) will return null if the value was never initialized or never dynamically created. Yeah, it is an incredible feature. What is really nice is that I didn’t have to create the MyPolicy object at all! In the Groovy world I could write the following:

def p = new Policy()

p.policyNumber = "12345678"
p.value = 12000.00
p.interestRate = 2.3

println p.policyNumber
println p.value
println p.interestRate

/* new property */
p.myNewProperty = "Active"

println p.myNewProperty

Later on I could even write:

/* another new property */
p.myOtherNewProperty = "Wow"

println p.myOtherNewProperty

This would save me some time and now because the Policy object is expandable, other applications that need to extend the Policy object, for application purposes, will be able to utilize these features. I am convinced, Groovy IS productivity for Java.