The pendulum has swung once again and I have escaped the world of architecture to get back to delivering software. I left Bank of America (Countrywide) for the second time last week, but not the mortgage industry. I am now the Application Manager for the origination system Nationstar Mortgage.

The challenge for my first week has been getting my head around the codebase. The application is a combination of a vendor solution along with a lot of custom code built up along the side. Like a lot of in house applications which started small, this one has grown in to what I call the “big ball of mud” pattern, where there was not the long term vision and architectural rigor for structuring a scalable, maintainable application. The fun part is it is my job to fix it.

After a week of looking at code, I have acquired new-found love for strong typing. In a mad genius, army-of-one development mode, the freedom of dynamic languages is both liberating and powerful. But as you start to add more cooks to the kitchen, things start to go downhill rapidly.

Case in point, I was attempted to troubleshoot a sporadic NullPointerException that pops-up in production. The culprit method is getting an object out of a list, and calling a method on a nested object it contains. I’m trying to determine if the object itself is null, or if the nested object is missing, so I’m tracing back how to where that object comes from.

The problem is that the instance of the object comes from an ArrayList, which is created from an object in HashMap, and neither makes use of generics. I know what my final object is supposed to be, but I have to trace back through other code to see how that the HashMap is being populated with.

This whole codebase has left me begging for generics. Generics in Java are not just about type safety, they are about documenting your code. For example, instead of:

ArrayList myLoans = new ArrayList();
HashMap properties = new HashMap();

You should make use of generics so that other people aren’t left guessing on the contents:

List<Loan> myLoans = new ArrayList<Loan>();
Map<String,Address> properties  = new HashMap<String,Address>();

In the second case, I know I have a list of Loan objects, and I know I have a map where the key is a String and the entry is an Address object. I don’t have to jump around in the code to see how they are used to understand exactly what they contain. Note another difference: I use the collection interfaces (List, Map) in my declaration rather than the implementation classes (ArrayList, HashMap).

From an object-oriented programming perspective, you should always strive to hide the implementation details of objects. And by using the interface, you buy yourself the flexibility of being able to swap out for a new implementation class without breaking the code. For example you could change the ArrayList to a Vector if you needed the synchronization and not break downstream code.

So with my dive back in to the bowels of enterprise software development, I’ve regained a new appreciation for my old friend Java. There is great strength in strong typing which permits you to build much more maintainable applications than the alternatives. Use that strength and make your team happy.

This is the story of Abel, a hard-working, dedicated Java developer. One night, after a hair-pulling coding session with Spring Security, Abel was visited by the Ghost of Java. “Abel, you have been extremely dedicated to me,” said the Ghost, “and for that, you will be rewarded.” “You will be visited by three ladies of the night as a reward for your years of sweat and turmoil hacking me,” the Ghost continued.

Two thoughts quickly raced through Abel’s mind. First, being a Java developer, it meant he would actually have to shave and shower for the next three days. Second, being a dedicated Java developer, three ladies in three nights might be a bigger task than he could handle. But throwing caution to the wind, he told the Ghost of Java he was up to the task, although he mentioned he would have preferred Java 7.

On the first night, a rather mature woman, slightly past her prime, showed up at his door. She was perfectly dressed in a revealing blue dress, but her exquisite makeup was not up to the task of concealing her sags and wrinkles. She said her name was IBM and that she would show Abel a good time. What she lacked in looks she made up for in conversation. She treated Abel like the center of the universe and was always ready with a supportive comment or another glass of expensive champagne. Abel was somewhat satisfied with the happy ending to the evening. It wasn’t spectacular but IBM made sure he knew it was all about him.

Abel’s second night took an abrupt turn for the worse when the next lady walked in. Looking like a crack whore in a thousand-dollar mini skirt, Abel’s new date introduced herself as Oracle. Upon seeing her, Abel’s first reaction was to put his hand on his wallet. Unlike his prior date, Oracle made clear the world revolved around her. She talked all night about the great many tricks she could do for Abel, but all for a price. Abel was thoroughly distracted from the happy ending between trying to keep an eye on his wallet and worrying he might catch something from his new date.

On the third night, Abel hid in his closet, fearing a repeat of the second night. Instead, he was pleasantly surprised when a curvaceous, girl-next-door redhead came in to his room and introduced herself as Microsoft. Although not much for conversation, Microsoft had curves in all the right places and not a wrinkle to be found. Abel got a chuckle over how she liked spinning in the flowers and talking about her MySpace page. The happy ending was very easy; so easy in fact that he wondered how he would ever be satisfied with anything more complicated again.

Abel’s plight is one that many Java developers have run through their head this past week as news made it out that Oracle had purchased Sun Microsystems. IBM, the aging monstrosity it is, would have killed Java through neglect. Oracle, the crack whore of software, will possibly kill Java through trying to monetize (read “nickel and dime”) the development community to death. And then we have Microsoft, with C# 3.5, whispering sweet nothings in developers ears.

So what is a Java developer to do? I fretted over this most the week so that I could be more rational when I put the pen to it. IBM owning Java would not be pleasant due to IBM always managing to be five years behind the technology curve. While that might be popular with large enterprises, it does nothing to please the alpha geeks that made Java what it is today. We can joke about Java being the new Cobol. IBM would have guaranteed it.

About the only worse possibility would be for Oracle to own Java, which is where we find ourselves today. Whereas Sun was an engineering company, Oracle is a sales company, and software developers strongly prefer dealing with the former. I have no doubt that Oracle will try to find a way to monetize Java, to the detriment of the community.

Finally, we have the wildcard Microsoft. C# is not much a leap for a Java developer. And having sampled their forbidden fruit, there is definitely something to be appreciated. Microsoft would be more than happy to offer disenfranchised Java developers a new home.

But ultimately, there is another option, as Rod Johnson pointed out. Through the open source community, Java has grown beyond any one vendor. Yes, Oracle may try and stifle this community through a future Java release under a restrictive license which breaks compatibility with open source Java, but that would only cement their irrelevance.

Oracle’s ownership of Java means that the fate of Java is now in the community’s hands and not a vendor’s. There will not be much love for Oracle with Java developers, so I expect the next version of Java anyone cares about to called JDK 7 and not Java 7. And it will be a true, open effort of dedicated developers and the Java ecosystem they have grown. So as tempting as it is to cave in to C#, I’m going to stick with Java for now and see where we can take this.

I didn’t have to wait long to prove out my first prediction for 2009. Big Blue is apparently in talks to buy Sun.

I have pretty mixed feelings about this. It means Java would be safe, but it would also be dead. IBM is a technology dinosaur, usually running several years behind the pack in the Java space. This would mean the end of innovation at the JVM level and the chances for a Java 7 any time this decade probably go down to zero.

IBM might also try to start monetizing the JVM. While it would be an incredibly stupid thing to do, never underestimate the stupidity of IBM.

The only bright spot will be what gets built on top of the JVM. The JDK 1.6.0_12 is a high-performance, stable beast of a platform. Things like Groovy and other JVM-based dynamic languages are the future of Java, so at least they’ll have a stable core to build on.

Not to be outdone by the innumerable quantity of pundits out there making their own baseless predictions, I’m going to toss out my own for the coming year in the technology space:

1. Sun Microsystems is toast. Their only real asset is Java, and it is worth more to a company like IBM or Oracle. If the frigid economic climate continues, Sun will be purchased by IBM.
2. Windows 7 will rock. This prediction might get delayed until early 2010 given Microsoft’s track record, but I fully expect Windows 7 to put Microsoft firmly back in the drivers seat. It will make up for past sins and put Apple on the defensive.
3. Google and Apple turn out to be evil after all. Pretty safe bet; both want to be what Microsoft was last year and will sell their souls to do it.
4. Microsoft won’t be the evil empire any more. Now that Bill is gone and Ray Ozzie is setting the tone, you’ll see a lot more warmth and geek-friendliness out of Microsoft. Check out Microspotting if you want to catch a glimpse of the new Microsoft.
5. Oracle will buy Spring Source. This is about the only jewel they’re missing and would be a better investment than BEA was. Unfortunately, it will kill all the enthusiasm around the Spring Framework, thus killing one of the few exciting things left in the Java space.
6. (Wildcard) Microsoft buys ExtJS. Apple picked SproutCore, so Microsoft needs a good RIA JavaScript library. They’ve put their backing behind JQuery, which is awesome, but it is not in the same league as ExtJS. They could buy ExtJS for a pittance and have one of the best AJAX widget libraries on the market overnight. ExtJS and ASP.NET MVC will be the winning combo.

I was at a Christmas party this past weekend and was talking with a friend I hadn’t seen in a while. I was telling him about my new job and mentioned that it was Java, but I was hoping to get a chance to do some .NET too. He said his recruiter friend told him she can’t find Java people anymore.

I was slightly surprised at this. The DFW area has a lot of Java talent, so the only reasons I can think of are:

1. Pay sucks: you won’t attract A-list Java talent with a VB-coders salary
2. WebSphere Application Server: every good Java coder I know would gladly chew off their own arm to escape having to work with this piece of shit.
3. .NET: 80% or more of the top Java guys I have known throughout the years have moved to C#

It is this combination of things that will limit the Java talent pool. The last one, .NET, cannot be understated. .NET 3.5 is a lightyear ahead of Java 6 from a programming language standpoint, and .NET 4.0 doubles that lead. The saving grace for Java right now is the Spring Framework, which is simply phenomenal.

So here are the things needed to attract top Java talent in DFW.

1. Minimally Java 5, and preferably Java 6
2. Spring Framework
3. Deploy to Tomcat
4. Agile methodology
5. Embracing of the open source toolset
6. Salary in the 110-120K range

This probably applies nationally, but adjust the salary to market conditions. A true senior Java developer with the kind of experience people want should easily be in that pay range. Hiring managers are deluding themselves if they think they can get top talent for 90K. I don’t know a senior Java guy worth his salt who would get out of bed for 90K.

One of the most impressive features of IntelliJ IDEA has been its support for the Spring Framework. IDEA 7 had great Spring support, and IDEA 8 expanded it to include Spring 2.5. What makes Spring a dream with IDEA is how well it understands the Spring grammer and configuration files. I’ll give some basic samples so you can see what I’m talking about.

Let’s start with some very basic beans implemented as interfaces and implementation classes. They are:

This gives us a very basic interface for a Car and simple implementation. Not quite HelloWorld, but close. The Driver interface and implementation look like this:

Again, a very simple implementation. As you have probably guessed, we’re going to define two beans and inject the Car implementation into Driver. Just to make things interesting, we’ll also use a properties file so we can do some token substitution. Our file, called driver.properties, looks like this:

Now lets get to work and implement the Spring XML configuration file. With the above classes implemented, one of the great features of IntelliJ is great support for the p: namespace. IntelliJ has auto-completion for the beans properies, as you can see in this image:

As you can see, since we gave the name of the implementation class, the parser picked up the names of the setters and made them available via the p: namespace. Of course, there is also full auto-completion of the class name, so no copy-paste is needed.

The same auto-completion is available for properties in the imported properties file. Here is the import statement and the auto-complete pop-up as we’re filling in the property for the Driver’s name:

As you can see it enumerated both the property names and their values from the properties file configured in the property-placeholder.

The Spring support also extends from the back source to the configuration. With the Spring XML configuration file in the project, IntelliJ will detect it and provide hints in the code for Spring beans, including quick navigation between the code and the configuration. Here is what the Car interface now looks like with the Spring configuration:

As you can see, IntelliJ puts a “bean” marker in the left margin next to classes or interfaces declared in the Spring configuration file. Clicking the marker will open the Spring configuration file, highlighting the configuration line for the bean. You’ll also notice the little “I” in a circle. This is a basic IntelliJ feature which means a class has implemented the method and can navigate directly to the implementation. If multiple classes implement the interface, you can choose which one to navigate to, like this:

Clicking the little “I” next to the line declaring the Car interface brings up a dropdown allowing you to pick which implementing class you want to navigate to. The same applies for the method declarations.

Spring also has quick navigation of bean properties. For example, in my Spring configuration file, I have declared my car bean like this:

If we take a look at the class file for CarImpl, you’ll see that IntelliJ has placed a marker next to the setter methods to indicate they are Spring properties being set in the configuration file:

Clicking the property marker takes you directly to the definition of the property in the configuration file. The reverse is also true. Using CTRL + click on a property in the configuration file takes you to the implementation in the class file.

It is all this goodness that makes working with Spring such a pleasure in IntelliJ IDEA 8, and this only scratches the surface of how powerful a code editor it really is. Give it a try and enjoy!

The latest version of my favorite Java IDE, IntelliJ IDEA 8, was released today. I’ve been using IDEA since version 2.0 and have consistenly upgraded my personal license every new release. This time is no different. IDEA has been my favorite IDE for the simple fact it is the ultimate coders tool. No other IDE I have ever used has been so good at helping me with the things I need while staying out the of way the rest of the time. There is not a better Java development environment on the planet.

Yes, I’m sure I’ve offended the Eclipse mafia. I have used Eclipse, on serveral occassions. But I go back to IDEA every time. It is hard to describe the difference in feel between the two. Eclipse is like a swiss army knife — it does a little bit of everything, but none of it particularly well. IntelliJ IDEA is like a Spyderco knife, the perfect cutting instrument. Eclipse is the Visual Basic to IntelliJ IDEA’s emacs.

So what’s new with IntelliJ IDEA 8? The coolest thing I’ve used so far is the built-in JavaScript debugger. You no longer have to depend on Firebug to debug JavaScript files in a project, you can simply set breakpoints in the JavaScript and run the page. For the full list of the new features, check out this page. I’ll be doing a more in-depth review of IDEA 8, using it with a Spring MVC web project.

If you haven’t tried IntelliJ IDEA, and you’re a Java developer, I strongly encourage you to check it out. Personal licenses are only $249 and they are well worth it. Eclipse may be free, but you get what you pay for.