Thursday, December 20, 2007

Hudson Continuous Integration

We recently switched to Hudson on a large project I am working on. Hudson is a continuous integration server with excellent maven, ant, and shell script support. It also has a wide variety of support for source control providers (i.e. svn, cvs, etc), Hudson has a nice plugin extension framework which is evident by the volume of plugins available for it. Previously, we were using continuum, which we had been using for about a year, but it eventually left a bad taste in our mouths. Hudson seems a lot cleaner, simpler, and more extensible. We now have a pretty sweet setup of SCM tools. We are using subversion for source control. Sventon as a web-based subversion browser. Maven for software builds. JIRA for issue tracking, and Hudson for continuous integration. In addition we have integrated: JIRA with subversion, so that JIRA periodically parses svn commit comments for issue numbers. JIRA will then display a link through sventon to the files associated with an issue. Hudson and sventon, so the changeset list in Hudson links to the source through sventon. Hudson with JIRA, so the changeset comments link to relevant issues in JIRA.

Wednesday, December 12, 2007

Progammatically Compile Java Code

I had planned on writing a summary of how to compile Java code programmatically using the package in Java 6, but this article pretty much sums up everything I would have said. In short this would allow you to store source or "source strings" in a database or file system and compile them without "shelling out" and utilizing a specific javac. I had been thinking about using javax.script packages to accomplish a dynamic code goal on one of my projects, but I think I'll also use this approach and let the "end user" decide which extension point they would like to utilize. The approach would allow significant performance gains due to having compiled code which would take advantage of all the JRE optimizations (i.e. JIT). I need to look into the javax.script implementations to see if a similar compilation is possible or if scripted code remains interpreted forever.

Tuesday, December 11, 2007

Wednesday, December 05, 2007

Java and the Google Earth COM API

Using com4J, I managed to utilize the Google Earth COM API from a Java application. Here's how: 1) Using com4J, generate java source from googleearth.exe:
java -jar tlbimp.jar -o ge_code -p "c:\program files\google\google earth\googleearth.exe"
This command will cause com4j to generate java source in the ge_code directory inside the package. 2)Now use the generated code in your own code:

public class GETest {

    public static void main(String[] args) {

        //Launch Google earth unless it's already open
        IApplicationGE ge = ClassFactory.createApplicationGE();
        //Load kml from the network
        ge.openKmlFile("http://localhost:8080/ff.kml", 1);

        //Load kml from the local filesystem
        ge.openKmlFile("c:\\dir\\ff.kml", 1);

The Google Earth COM API allows you to load kml data from a file or network location as shown above or as a string with the loadKmlData method. You can also get handles to Features and set the visibility. So far I have not found a way to programmatically refresh network links which is what I was really after, so I'm open to suggestions there. The COM API seems a bit limited in what you can accomplish, but maybe we'll see more in future releases. From the experience I've garnered that com4j is a very easy to use tool, and made interacting with Google Earth a breeze.

Saturday, December 01, 2007

SCJP for Java 6

It appears Sun has quietly released a Sun Certified Java Programmer (SCJP) Exam for Java 6. The exam objectives look strikingly similar to the Java 5 test. Someone at JavaRanch points out the only differences in the 5 and 6 exam are the Console, NavigableMap, and NavigableSet classes. My theory is Sun is simply trying to get tests relabeled to remove the Java "2" insaneness. Not to mention this is likely not a trivial revenue source for them as it is their most popular test. I'll likely not take this exam unless I get excess free time. I don't feel the benefit is there over my current SCJP 5 cert. I'll likely be holding out for the Java 7 exam.

Monday, November 26, 2007

More Effective Java News

Amazon now has the release date of June 2008 for Effective Java 2nd edition. I'm still betting this will be released at JavaOne 2008 (if ever). Anyhow, I've canceled my order. I'll reorder at a more appropriate date. I sent a query to the publisher, but I received no response. I think perhaps they could use a customer service lesson. Here's a hint, always respond to the customer even if you don't have any news for them. Enough venting.

Friday, November 16, 2007

Fork-Join Framework for Java 7

Brian Goetz does a good job explaining an upcoming Fork-Join framework for Java 7 here. Doug Lea also describes it here.Initially I thought the idea was kind of lame because Java has had very good threading support from the beginning, so this is nothing you couldn't do yourself. It does however continue extending upon higher level abstractions appearing in the java.util.concurrent package. In particular, I like the discussion of "work-stealing" which makes this framework actually make sense over the naive approach of a new thread per recursive task. Work stealing seems like such a smart idea especially when coupled with a work deque instead of a work queue That way work stealing can happen from the tail instead of the head, so thread contention with the normal(non-stolen) work is reduced.

Monday, November 12, 2007

Effective Java 2nd Edition ???

Update2: Amazon is now showing the release date as May 28, 2008. Pearson (the publisher) is showing the release as March 25, 2008. Update: Amazon has changed the release data on this book to November 30, 2007. I suppose I'll keep watching. Well, I've been waiting for this book for a long time now, and Amazon says the release data is November 9th 2007, yet It's is already November 12th and the book is still available for "pre-order". Hmmmm, is this yet another delay on this book? The shipping estimate on my copy is still tomorrow. I have my doubts. There is a mysterious lack of buzz about this book. It has been discussed with much anticipation at the past 2 JavaOne conferences. I now have little hope that it will be released this year. If I had to guess, JavaOne 2008 will be the release. I'm so disappointed. Oh Well.

Thursday, September 27, 2007

JDK Logging Improvement

I've submitted an RFE to Sun for a simple addition to the JDK logging framework. If your code is logging intensive then you should love this addition. Don't you simply hate wrapping a conditional statement around your logging code to avoid unnecessary string concatenation like this:
if(logger.isDebugEnabled() {
   logger.log(Level.DEBUG, "Hello Brant " + string1 + string2 + object1 ");
If you hate doing this, then my RFE has a solution for you. My suggestion is to utilize printf-like syntax and varargs for a method signature of something like this:
logf(Level level, String format, Object... params)
Which would change the syntax to something like this:
logger.logf(Level.DEBUG, "Hello Brant %s %s %s", string1, string2, object1);
I would also include bonus points for being able to determine if the last object in the varargs list was a throwable and logging the stack trace. Or some other mechanism of including a throwable argument in the method signature. Maybe like this:
logger.logf(Level.DEBUG, "Hello Brant %s %s %s", string1, string2, object1, ex);
I'll admit that this is not entirely my idea. My fried Glen actually developed a logging wrapper framework which included this. He did a very nice job with it, I however am less inclined to utilize yet another log wrapping framework or force an internal logging framework onto users of my libraries. I'd prefer this just be available to people wanting to use standard JDK logging. I believe Glen has taken the idea to the SLF4J group. If you like this idea, I urge you to vote for the RFE at

Tuesday, January 09, 2007

Java Generics (and Collections)

I just finished reading the Java Generics book by Maurice Naftalin and Philip Wadler. I already had a good handle on generics as I have been using them for a couple years, but in general I had a difficult time explaining the more complex uses to other developers. So, I picked up this book as a reference to help me explain/justify the way I have been doing things. The first half of the book is specific to generics while the second half of the book is about the Collections framework. The book does a good job covering generics in collections, generic methods, type tokens, reflection, and recursive generic definitions. Overall, I thought the book was written very well an organized in a fashion that makes it very readable. I thought the coverage of Generics was very clear and concise, and I would recommend this book for people wanting to learn about Generics or as a good reference for the more experienced. At first, I thought the Collections half of the book was basically there as filler material, but I was quite surprised to actually find it relevant. The book very thoroughly covers The Collections interfaces and their implementations which are provided in the standard JDK including Java 6. The book even provides several handy tables comparing each implementation's time complexity. Just in case you didn't know, another spectacular Java Generics resource is Angelika Langer's Java Generics FAQ.