It's taken me years, but I finally got over import java.util.*;. First, I don't use an IDE. I know an IDE could manage my imports, but I'm not an IDE guy. So, for years I've managed my imports manually, or given up and done import java.util.* and felt guilty about it. Well, I'm over that, and I can give Groovy the credit. By default Groovy imports java.util.*. I've been using Groovy every day now for about a year and a half and the house is still standing, our code compiles, we haven't had name conflicts. Things work, and it's a lot easier.
I used to worry about name clashes and compilation speed, and other shiboleths spoken of around coder camp fires and in hushed tones. After all everyone "knows" that the * should be avoided. Well, I'm over it, import java.util.* is just fine with me. Now when I start a Java source file I almost always just add java.util.*.
Although Java isn't thought of as a dynamic language now a days, what with Ruby and Groovy being all the rage, Java does have support for dynamic features. (See my previous blog post on the subject and the solution I came up with.)
Currently I'm wrapping about a hundred EJB 2.1 LocalHome classes in DAO's, and having them transform local EJB entities into POJO's. Much of the code is largely boiler plate. Actually it's mind numbingly boiler plate. Here's a sample of wrapping a finder:
(Related article using this technique to "script" some Java objects: article.)
The following code quickly illustrates an issue with the Reflection API's in the Java language. At run time finding methods on classes requires that the types passed to Class#findMethod() exactly match those found in the method declaration. The JavaDoc and language spec refers to these as the "formal parameter types".
The issue is, I have a method that takes an A, and I have an object of B that extends A. If you run the following code it will fail, being unable to find the method.
Although talk about multiple languages running on the JVM has grown over the past few years, the reality of it really hit home with me this morning. I turned to one of my employees who has been doing JVM development for me since April of last year. The interesting thing is probably 95% of the JVM work he has done isn't in Java, it's in Groovy. Here's to the multi-language Java platform and a thank you to those developers who are making it a reality.
January second's Daily Drucker dealt with the future, but not as most business prognosticators or futurists might. As Drucker states it, "The important thing is to identify the 'future that has already happened...'"
The action point for the day is to identifying those trends in our market that have already happened, write about their longevity and their effect on our life and organization.
Over the past few years, and particularly in 2007 Software as a Service (Saas) has really broken out and has become a force in the software industry. The first large scale SaaS offering that really broke through to my consciousness was Salesforce.com, then for me came Basecamp from 37signals.com. Salesforce.com represented a high level enterprise offering, with a high level of complexity and expense. Basecamp brought software as a service home to us all.
Sylva and I got married on April 28. It's been a real whirl wind since then. We are expecting our first child on April 1, 2008. My time with Sylva is special and precious. I have a great partner, and look forward to raising a family together.
Overall business issues have dominated this year. I doubt that will be that case next year.
It was a hard business year, but prospects for the future look good.
Quadran has arrived. About 63,000 lines of Groovy, Java and JSP, with some XML files to wire it all together, and it's up and running. We turned on our first Quadran installation on December 5, 2007. This was the culmination of a process that began with an initial meeting in September of 2004, and the consummation of the development agreement in July of 2006.
Today is the first day we have our client's complete staff using Quadran. It's a good feeling. This is a day years in the making. We had our first meeting about this project in the fourth quarter of 2004. That's a long time ago. We started the actual project in July of 2006. Today we have everyone in the business running on Quadran, and using their old system in parallel. There are issues, but nothing fundamental, no burning houses, or staff jumping off the ship. Overall it has been a calm deliberate test.
We have created more automated test cases for this project that any other project I have ever worked on. In the early going I opted for Struts 2, POJO service beans, and JPA, because they were testable. I think this has paid off pretty well, because it's quiet here. I'm not hearing screaming and gnashing of teeth. We'll see what the rest of the day brings.
Create a list of the hardest things to accomplish in software development and I'm sure near, if not at the top of the list, will be replacing an existing system. Especially a system that runs the lion's share of a business' operations. Especially when you can't look at the source of the system you're replacing.
For the past year I've been working on my Quadran project. Quadran is a drop in replacement for a system my client has been using for about five years. Completing Quadran has been just about the hardest things I've ever done. It has felt like an IT death march.
I received an email from ApacheCon today. They have accepted my Using Groovy with Struts 2 training session.
Using Groovy with Struts 2: A hands on half day training session. Learn how to use Groovy with Struts 2. Topics covered will include: Integrating Groovy into the Struts 2 Maven archetype; implementing actions, and service beans in Groovy; using Spring to wire Groovy service beans and action classes; using dynamic Groovy actions that do not require a server restart; writing Data Access Objects in Groovy and using Spring based transaction support with Java Persistence API (JPA).
I don't have scheduling information yet, but I believe it will either be on November 12 or 13. Stay tuned for more information.
Controlling access to web resources with a a login process is a common use-case. Implementing this using an interceptor in Struts 2 is very straight forward.
The parts of the solution: