I've recently come across a situation where I had to construct a GWT package in a jar file, something similar to gwt-user.jar. This describes why I wanted to do this and how to do it with maven.

In GWT application you will have some classes that are passed between the client and the server. These classes need to be marked with the IsSerializable interface and their source code needs to be available to the GWT java to javascript compiler. For a simple application these are most easily defined in the client portion of a single GWT package, which is build by a corresponding maven module. With larger projects, for ease of development and maintenance, it's better to treat the GWT package as a client and it's facade and to move the server code to its own maven module. The GWT package still has a server portion but it's a thin layer that calls through to classes from the main server module. Now though you have the problem of where to put the classes for client server communication.

I'd like to be able to construct the server independent of the client so that it doesn't depend on any GWT code. This gives me two choices. The first is to have the server portion of the GWT package convert from the data transfer objects provided by the server module into the data transfer objects defined by the client portion of the GWT package. I'd prefer to avoid this extra work so what I wanted to do is define a set of interfaces for a factory to construct the DTOs and the DTOs themselves. Then the server code could be programmed in terms of the interfaces, the DTOs in the client portion of the GWT package could implement those interfaces, the server portion of the GWT package could provide the implementations to the server module and all would be well.

To create a GWT package containing the interfaces I created a maven module with very simple module file.

<module>
  <inherits name="com.google.gwt.user.User"/>
</module>

For the jar file created from the maven module to work as a GWT package it must contain the GWT module file and the java source code as well as the compiled classes so that the GWT java to javascript compiler can access them. To do this I configured an additional plugin in the pom. I used the antrun plugin to copy the module file and java source into the target/classes directory.

<plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <executions>
    <execution>
      <phase>process-classes</phase>
      <configuration>
        <tasks>
          <copy todir="${basedir}/target/classes">
            <fileset dir="${basedir}/src/main/java">
              <include name="**/*.java"/>
              <include name="**/*.xml"/>
            </fileset>
          </copy>
        </tasks>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
</plugin>

There seem to be a few problems related to column aliases. There's the following derby bug report that describes the problem I've just run into. Though every other database lets you use column aliases in the where clause derby doesn't. The derby developers say that's fine cause that's what the standard says. Unfortunately that doesn't help anyone who wants to use hibernate, you can't use {task.id} = :id for instance, you have to say TASKS.TASK_ID = :id instead so sprinkling mapping info through your code. This is one of those cases where clinging to the standard and saying everyone else is wrong is a pretty silly thing to do.

I was setting up an experimental struts installation to try out some ideas and I had it configured to try and use a struts action as the welcome page. In web.xml I had.

    <welcome-file-list>
        <welcome-file>welcome.jsp</welcome-file>
    </welcome-file-list>

welcome.jsp used <logic:forward name="WELCOME"/> to forward to a global forward called WELCOME and in in struts-config.xml I had a global forward WELCOME defined as

  <global-forwards>
    <forward name="WELCOME"
             path="/searchresults.do"
             redirect="false"/>
  </global-forwards>

This is the standard setup described in Programming Jakarta Struts.

However, when I tried to execute this in tomcat I got the message javax.servlet.ServletException: Cannot find global ActionForward for name WELCOME. From looking through/debugging the code it appears that the method public ModuleConfig getModuleConfig(HttpServletRequest request) in ModuleUtils class wasn't managing to find the configuration. The comment for this method includes If no moduleConfig is found, this means that the request haven't hit the server throught the struts servlet which got me thinking. Turns out that the solution to the problem was to set load-on-startup for the struts ActionServlet. With this set in web.xml all worked fine.

For fun I'm messing around with Cocoa programming using the book Learning Cocoa (actually the 2001 first edition that I bought cheap from Half Price Books) and writing the examples in Java. At the moment I've got to the chapter on Cocoa's Multiple-Document Architecture and I spend a frustrating couple of hours trying to get the simple RTF example to work.

Whenever I started the application I would get a popup saying "No document could be created." and the Run Log window would show "The DocumentType type doesn't map to any NSDocumentClass.". I'd moved the NSDocument subclass into a package so I expected that when I set up the Document Class entry in the Document Types configuration I would enter com.zanthan.apple.MyDocument. Not so, the correct way to do this is to enter com/zanthan/apple/MyDocument. This information I found from this cocoadev post.

I've just made another quick change to XSLTXT so that it handles converting stylesheets from xml to xsltxt better. The issue was with handling large blocks of text. Each line would become a separate text "element" in the converted xsltxt file. I've now fixed this so that a single block of text in the stylesheet remains together when converted to xsltxt.

A recent discussion with the title of Unbreakable builds on TheServerSide got me thinking about Continuous Integration and how we apply it at work. The process described under the heading The Master Build in Continuous Integration is very similar to the one we use, but our build process is actually implemented using the product we develop, TeamWorks, to drive Ant scripts. At the moment the part we're lacking is some quick smoke tests for the whole product that catches the most frequent errors. A complete test cycle for one platform (app server), DB, and OS combination takes seven hours so while we don't checkin code that doesn't compile it's possible that the tests won't succeed.

Sadly I spent most of this weekend dealing with a problem caused by multi threaded Java code. Part of the system I develop is a multi threaded "server" that is used to run tasks in our main J2EE system based on schedules or the arrival of events. It was developed before the latest J2EE spec revisions so we don't use Message Beans or Timers yet.

For some time we've been getting the occasional report of the server "sticking". It looks like it is running a task that never finished. You can configure the server to run a set of tasks synchronously so if one of them sticks the rest will never run. Until this weekend our thinking has been that the problem has been with the task being run in the server not finishing. Perhaps it gets stuck in a loop or it finished but never reports back.

While testing some performance improvements we were finally able to reproduce the problem consistently in a test situation. From looking at weblogic we could see that nothing was actually running at the time, even though the server reported that something was. I took a look at the code for the server, and now that I knew what the problem wasn't it became clear that what it was was a race condition between the thread managing the queue of tasks to execute and the threads actually executing tasks. Data that was shared between threads was being updated outside of synchronized blocks. Still took a few attempts to tidy everything up but it's good to finally get the problem solved.

Just recording some experiences so that I can find them later, and in case they help others. At work we develop a J2EE application that runs on WebLogic (it also runs on WebSphere but that's not relevant here). Part of the application receives data via calls to session beans. The data is placed in a JMS queue for processing by message driven beans. This lets us smooth out peaks in the rate at which data is received as it doesn't have to be processed in real time.

A problem we have is that there can be collisions between different messages. In certain circumstances two messages will try to insert a database record with the same key value. The application handles this by requeuing the message that received the exception for later processing. No data is lost but we'd like to avoid the exceptions if we can.

The solution we've used is to place the data in one of several "virtual" queues by assigning a QueueNumber to each incoming message. The QueueNumber is calculated so that messages that will cause collisions all get the same QueueNumber. If each queue is processsed serially there will be no collisions.

The virtual queues are implemented using a single JMS queue by attaching a QueueNumber message attribute to each message. Message beans are defined for the virtual queues using message selectors that only pick up messages with the correct QueueNumber. On average each virtual queue will contain the same number of messages and be processed at the same rate so this shouldn't be too bad from a JMS performance point of view according to the BEA docs. For WebLogic if the max-beans-in-free-pool element is set to 1 in the weblogic-ejb-jar.xml file then we should only get one bean processing each message in the queue, so messages that could cause collisions will be processed serially.

However, while this all appears to work perfectly initially after a while threads will start to get stuck, especially as the load increases. We can reproduce this situation consistently. Taking a thread dump doesn't provide any useful info, at least not to us, as the threads that are stuck seem to be stuck in Class.forName.

We not been able to work out what the actual cause of the problem is, despite much google searching and thinking, but we have found a cure. If we increase max-beans-in-free-pool to 2 then we get no more stuck threads. We do now get some collisions, but not too many, and at least processing continues. From looking at some pages found on google other people with stuck threads seem to have max-beans-in-free-pool set to 1. Why this should cause the problem we don't know.

So the cry goes up for Simpler Java - Combatting the complexity of J2EE. But what exactly is this supposed to mean?

Of course what is means is whatever the particular writer things it should mean. For some people this means that it should be easy to develop a simple blog for a single user, for others that their read mostly dynamically generated web site should be able to scale easily by adding more machines to the cluster, and for still others that it should be easier to develop business critical applications that talk to DB2, and Oracle databases while integrating with SAP and providing a workflow solution using a third party open source toolkit.

I would say there is no answer to these competing requirements within the current J2EE. Like all of th options is Microsoft Word nobody needs all of the features of J2EE, everyone uses only 60% of it, but they all use a different 60%. To say it's too complex is to some extent to say that the problems that people are trying to solve are complex, and that's just the way it is.

One possible solution, and one that's worked well in other areas, is to enable the development of domain specific languages within Java. This would let each domain, for instance blog development, use their own language the provides the high level constructs they need while concealing the complexity if they don't want to deal with it. A problem of course is to be able to arrange for a smooth transition between the DSL and the Java code.

Anyway, rather than the development of yet more specific frameworks for specific situations perhaps it would be better to develop a DSL system for creating those frameworks?

I"ve been trying to extend log4j so that a program can set the logging level for an individual thread. This is so that we can easily log the flow of a transaction from the web tier, through the ejb container, down to the database and back. Implementing a Logger subclass to use a ThreadLocal variable to hold the current logging Level was simple enough.

The difficult part was to get log4j to actually use the subclass. What I wanted was to be able to write Logger log = Logger.getLogger(Foo.class) and have my new subclass of Logger returned. It looked like it would simply be a case of implementing a new LoggerFactory and specifying it in the log4j config file. No such luck. The documentation describes how to do this in some places but says it's no longer supported in others. Experimentation indicates it's no longer supported. Looking at the code for log4j indicates there is now a much clever scheme suitable for JBoss etc. so that they can install there own logging systems.

Fortunately for what I want I can control the actual class used by simply writing Logger log = MyLogger.getLogger(Foo.class) and using the getLogger(String, LoggerFactory) call inside the getLogger method. Time for some python code for mass search and replace now!

I've just created a new Ant data type that I think other people may also find useful. Of course, I've probably just duplicated someone else's work but it was still fun.

It is designed to let you externalize definitions that are common across multiple build files, or even projects, into one or more reusable common files. The inspiration was IntelliJ IDEA's library facility. To do this the new type adds all of the refs from an Ant project file into the current project. An example usage is

<load_external_refs location="common_paths.xml" refidPrefix="ext."/>

This will take all of the refs defined in common_paths.xml and add them to the project that contains the load_external_tasks element, prefixing each one with ext.. For instance if common_paths.xml includes a path element defined with a ref="junit" attribute then this will appear as a ref ext.junit in the project that includes the load_external_tasks element.

Before you can use load_external_tasks you need to tell Ant about it with a typedef element.

<typedef name="load_external_refs" 
             classname="com.zanthan.ant.LoadExternalRefs">
    <classpath path="lib/zanthan_ant.jar"/>
</typedef>

The compiled code is in zanthan_ant.jar while the source, including a quick example of it's use in build.test.xml, is in zanthan_ant_src.jar

Just a couple of the more extreme JavaDoc standards I came across in a brief search.

Exhibit One: EMBOSS: Code Documentation Standards The parameter codes and argument codes just seem over the top. If the code is so long and convoluted that you can derive that info from a quick inspection then it probably needs refactoring. Also looks like it would rapidly get out of date, are you really going to maintain a coded indicator for each parameter. For APIs I could see that more info might be useful but the Sun APIs don't use all of this stuff so why should you?

Exhibit Two: DJVM Coding Standards - DRAFT Again, I think the danger is that the doc will become out of step with the code, then both are wrong. For instance, are you really going to maintain all this information about each method.

         /**
          Description
          Method Parameters 
          Return Value 
          Preconditions
          Postconditions
	  Invariants
          Known Bugs
          External method calls
          Exceptions Thrown 
	  Concurrency Issues
	  Deprecation 
	  Visiblity Issues
          Date Created
          Author 
         */

I'm currently trying to sort out some code that is having problems with the way it uses exceptions. At the lowest level an exception specific to a package we're using is being thrown. At the highest level the GUI is trying to switch from one tab to another. In between are all sorts of layers. The original solution in the code is to catch the low level exception, wrap it in a RuntimeException and rethrow. Not much of a solution as at the higher levels I can't see what sorts of things might go wrong. On the other hand passing a lot of lower level exceptions up through the hierarchy couples layers of the code that should remain separate. Here are Rod Waldhoff's much more articulate thoughts on the matter. They conclude by introducing ExceptionRuntimeException, a very nice technique. Java's checked exceptions were a mistake (and here's what I would like to do about it)

Is it true that Java Is a Language for the Masses. The discussion on LtU is interesting, as usual. I prefer the gradual and slow addition of features to Java and I'm not sure I'd support macros. On the other hand, we do generate a lot of code at work using our own XSL/XSLT templates, and that is, to some extent a macro replacement, though I find it easier to deal with. Both approaches introduce project specific notations, with the XSL approach though the final result is still java that anyone could read. Macros provide the danger/opportunity of producing a different language. This is something the java metadata JSR is quite specific about. They don't want people writing new control statements using metadata because of the danger of language fragmentation that would arise. Something similar happened with JSP taglibs and the new standard taglibs are an attempt to bring things back together again.

The behavior of getTime() on java.sql.Timestamp has changed between 1.3 and 1.4. It used to return only integral seconds in 1.3, it now also returns milliseconds in 1.4. So, my code, which works fine in 1.3 for getting a time accurate to milliseconds, aTimestamp.getTime() + aTimestamp.getNanos() / 1000000 fails in 1.4. I now have to write (aTimestamp.getTime() / 1000) * 1000 + aTimestamp.getNanos() / 1000000 so that my code works on 1.3 and 1.4. Anyway, here's the link to the bug Bug ID: 4679060 Documentation of java.sql.Timestamp.getTime() is contradictory

Not so obvious when you've stared at it for a while, at least that's what I found. It suddenly jumped out at me though, thankfully.

executeStatement("SELECT A, B, C, D " +
                 "E, F " +
                 "FROM FOO " +
                 "WHERE A > 10")

How many columns do I get in the result set and what's the value in column D? If I execute resultSet.getObject("D") I actually get an invalid column name exception. Looking at the result set metadata I see 5 columns, called A B C E and F. Where's D gone? The value returned by resultSet.getObject("E") is actually the value of column D.

It's obvious though when you realise I missed the comma off the end of the list on the first line, doh! The database then renamed D as E, as it's supposed to, in the result set. Hard to spot when the code is formatted like this though. Especially hard when you don't think of such things and check everything else, well nearly everything else, first.

Some time later this year we're probably going to replace the O/R mapping tool we use at work. There are a lot of alternatives out there, of various degrees of complexity and "completeness". One possibility is Hibernate and another is SimpleORM. They illustrate pretty well the two ends of the spectrum.

Hibernate describes itself as Hibernate is a powerful, ultra-high performance object/relational persistence and query service for Java. Hibernate lets you develop persistent objects following common Java idiom, including association, inheritance, polymorphism, composition and the Java collections framework..

On the other hand SimoleORM says It provides a simple but effective implementation of object/relational mapping on top of JDBC at low cost and low overhead. Not even an XML file to configure! Beyond pure Java, SimpleORM is 100% Clean Java. Minimal reflection, no pre processing, and certainly no byte code post processing(!) This simple and elegant framework does not require any clever tricks.

It's going to be interesting to decide which end of the spectrum we want to be at. We have a pretty extensive framework we developed ourselves for everything apart from the actual persisting and retrieval of the data. So we have to decide, do we want to replace all of the current framework with something like Hibernate, or just the O/R mapper code with something like SimpleORM.

So this is pretty embarassing. I'm trying to remove messages from a JMS queue. I created a message selector that selected the messages I wanted to remove. I created a receiver using the selector but when I called the receive method I didn't get anything back. I tried receive(), receive(1000), and receiveNoWait() and nothing worked. However, if I created a browser with the same selector I saw the messages I wanted.

Turns out I forgot to call start() on the connection before calling receive() on the receiver. Hence no messages. Oh dear.

For Christmas my son was given one of those puzzles where you have to place tiles next to each other in a square so that the symbols on the touching sides match. This particluar one is called "The Valley of the Kings" and is published by PuzzleAdventure. As soon as I saw it I thought, this is going to be far easier to solve by computer than by hand.

I've just got round to putting together a Java program to produce a solution. I picked Java over perl or python or scheme mainly because I could use IntelliJ for development. I must admit Haskell was tempting as there are no IO requirements, just algorithms. On the other hand, I'd have had to spend a lot of time with the manual just to deal with the syntax, as I've not used it for so long, and was never very familiar with it in the first place.

It took about two hours to write the program using IntelliJ. I implemented a very simple brute force approach. It just starts in the top left and recursively tries each tile in each possible orientation in turn until it finds a solution. When a solution is found an exception is thrown to take the solved layout back up to the top level. As it finds the correct solution in 656 milliseconds it turns out it's not worth performing any optimization.

Personally I found writing the program to find the answer a lot more fun than trying to find the answer by hand but it's probably not what the puzzle makers had in mind.

The problem is you never seem to have enough time to do the job properly! By dint of hacking around it's certainly possible to get something to work but it takes a lot longer to become comfortable with all of the configuration possibilities and what is the best choice as opposed to a choice that just gets stuff working. The worst offender, in my opinion, is the security configuration. All of the critical stuff, such as hooking up the actual authentication, is left up to the container vendors. It may have to be this way but the fact that each new release of a container provides a new and different set of APIs for making this connection doesn't help.

He took the sequence diagram code I wrote and put it into an IntelliJ plugin. Not distributed yet but I look forward to it. Now I'm even more motivated to finish my cleanup project on that code.

I spend some time this weekend trying my hand at building an IntelliJ plugin. It's not ready for posting to the IntelliJ wiki yet but I'll link to it here. All it does is reproduce some functionality I previously built in emacs, the ability to insert a log4j logging statement that logs all of the parameter values passed to a method. It even inserts a field with a log4j Logger instance and the appropriate import statement if needed.

It was an interesting way to explore some of the IntelliJ plugin architecture, especially the program structure interface. This is a sort of abstract syntax tree, but including whitepace and comments, for the code being edited. It lets you pretty easily navigate the program structure and modify it. The downside it that it's completely undocumented and subject to change. The one thing I couldn't easily do was invoke the auto indent/reformat functions of the IDE. Theres a method called reformat on the CodeStyleManager instance but I couldn't get it to do anything. Any help greatfully received :)

Anyway, here's the plugin jar file and the source code. Enjoy.

I'm looking for some information on query rewriting and optimizing system. In particular rules based query rewriters. I want to be able to write a "query" in some declarative way similar to SQL and have it translated into a specification of the actions to carry out to implement the query. I've found a few papers, for example, Specifying Rule-based Query Optimizers in a Reflective Framework that describe the sort of thing I'm after. There are also a number of Java based rules engines such as drools, Jess and Mandarax that could form the substructure for such a system. Does anyone have any tips or pointers to share?

This tool, Macker, may be useful. I'll have to give it a try sometime. At work we check separation between layers by breaking the source code into different modules and ensuring that only the appropriate modules are included in the classpath at compile time. Each "application" is built by combining a number of different modules.

A little addon I developed for ant. It's an implementation of the org.apache.tools.ant.util.FileNameMapper interface that takes a .java file and returns the name the file should have based on its package statement. I needed it when I was generating code using the ant style task. All of the .xml files were in one single directory but the generated code had to go into multiple different directories depending on the package. After generating to a single output directory an ant move task was used like this example.

<move todir="${basedir}/src">
  <mapper classname="com.zanthan.ant.PackageFileMapper"
    to="" from="${basedir}/generated"/>
  <fileset dir="${basedir}/generated">
    <include name="*AutoGen.java"/>
  </fileset>
</move>

Here's the source code. It's so simple I don't think I need to post the supporting stuff needed to compile it.

At the moment the programmers working on IntelliJ are in the that excellent position of being able to use their product to write their product. I would imagine that IntelliJ is written using IntelliJ, and I think this must account for some of its success. Whatever is an annoyance to IntelliJ's users will be an annoyance to its developers first, whatever makes developing the product hard or slow will make using the product hard or slow, and conversely whatever makes development easier and faster will make use easier and faster. If you can arrange it so that your software developers are also your first software users it can certainly help your product.

It's going to be interesting to see how the EJB support in IntelliJ develops. Obviously IntelliJ does not itself involve any EJBs so using and testing that functionality won't be an intimate and inescapable part of developing it. Will they be able to come up with something as good when they're not working first to please themselves?

A couple of side notes. On my recent trip to Microsoft I noticed that several developers there used emacs instead of VisualStudio.NET to develop in. Clearly this is not a good thing. If you can't convince your own internal developers to use the product it doesn't bode well for outside users. Nathaniel S. Borenstein talks about this issue, getting editor writers to use the editor they're writing, in his great book Programming as if People Mattered. Doing it by fiat doesn't work. He says you need to provide some compelling feature that the current editor doesn't provide, and can't easily be hacked in. For me and IntelliJ that was the refactoring support.

At work we don't currently use our product to develop our product but that's certainly one of our longer term goals. Certainly whenever one of the developers has to spend any time working with the product they come back with ideas they immediately want to implement to make things easier. Our JMS based debugger for debugging processes executing on the server from an authoring environment running on a client machine was the outcome of one of these ideas. The more of the tool that is build from the tool using the tool the better it will be for us and our customers.

Obviously we also need to keep in mind the main purpose of our product but the more contact the developers have with product use the better. This is the idea behind some company's system of rotating developers throught consulting/professional services from time to time, to keep them in touch with what the thing they are developing is actually being used for.

In respose to a comment by gavin about my Editing with IntelliJ experience. I'm using my own set of keybindings. I've not made many changes yet though. When I was using the emacs bindings supplied I had the problem he mentions, useful IntelliJ functions were moved to weird places. What I did was copy the default keybindings set and mody them. Initially I just put the cursor control functions on Ctrl-f, -b, -a, and -e. Any IntelliJ ones in conflict I moved to Alt-. So find declaration went to Alt-b. After using emacs a lot Atl-b is no more weird than Ctrl-b. I'll probably make some more changes in the future as I use IntelliJ more and find things my fingers stumble over. It may be that Ctrl-i for tab, and Ctrl-j for enter are going to be the next ones. The way that IntelliJ handles sets of keybindings makes it easy to switch between them, and you can't change the supplied sets, so at least you can't screw things up too badly.

I spent some time over the weekend trying out IntelliJ for editing Java and I'm very impressed, which is surprising as I'm a real Emacs bigot. Once I got used to the keyboard shortcuts I'm found it a productive environment. The remaining thing I have remember is to let the IDE do the typing. With autocompletion, automatic management of imports, and a lot of refactoring support it's faster to type Ctrl+space and select the correct option than to type the text in yourself, provided you remember to do it! As for moving files between packages, it's the only way to go.

Anyway, my point here is a quick shell script I use to set up the external JjavaDoc support so that IntelliJ opens external JavaDoc files in a running Mozilla instance under Linux.

#!/bin/sh

if `mozilla -remote 'ping()' &> /dev/null`
    then
    mozilla -remote "openURL($1)"
else
    mozilla $1
fi

exit

In the IDE Setting - General set the Web Browser path to point to this script. In Project Properties - Paths - JavaDoc Paths add the paths to where the JavaDocs are stored. You need to set the path so that translating the package name into a file name, prepending this path, and appending .html will locate the correct JavaDoc file.

Via Simon Brunning I was pointed to this post, J2EE vs. NET, Java vs. C#, by Graham Glass.

It's an interesting read. I agree with his remarks about Java and C#. C# is a decent evolution of Java. There are a few point I don't like, for instance why reintroduce goto or why have to use virtual before you can use override? On the other hand attributes are very useful.

However, I disagree about with Mr. Glass about the relationship between .NET and J2EE. It may well be that J2EE appears more complex that .NET but I think this is for a very understandable reason. J2EE has been around a lot longer, and has been used to solve a greater range of real world problems than .NET. Sometimes it wasn't able to provide a solution, so things were added and J2EE has evolved to become more complex. .NET will go the same way; currently it looks simpler, in the way that Java was simpler in 1997, because it hasn't been around long enough to have to have it's limitations patched or overcome. I think there is a certain irreducible complexity in some problems and the framework used to solve them is going to have to address that, not everything is simple and easy to solve.

I've added code to XSLTXT so that it can be used in place of XSL in the Ant style task. Take a look at the longer explanation here.

I'm pleased to report that XSLTXT recently got mentioned in an article on IBM's developerWorks: XML zone that talks about alternative syntaxes for XML.

Coincidentally I'm using XSLTXT at work at the moment as part of a system for editing Java UIs with NetBeans. Rather than using the code generation facilities NetBeans provides I've developed our own that takes the xml description of the screen layout produced by NetBeans and transforms it with XSLTXT to produce a dialog class. This does actually have some advantages for us over using NetBeans directly.

• The generated classes are designed for extending by subclassing instead of by editing directly. This makes it much easier to manage our customizations of the generated code.
• We can generate additional code to link each UI screen to the persistent object that it is editing.
• We use a number of custom wrapper classes round standard widgets like JButton and have a few larger composite widgets as well. Having our own generation system is easier than setting these things up as beans so that they can be directly used in NetBeans.

More file renaming, this time in Java. Demonstrates why you wouldn't really want to do it this way. Sorry about the wacky formatting, I was trying to reduce the line length so it fits on the page better.

import java.io.*;

public class Rename {

    public static void main(String[] args) {
	File directory =
	    new File(System.getProperty("user.dir"));
	String[] textFileNames =
	    directory.list(new FilenameFilter() {
		    public boolean accept(File dir, String name) {
			return name.endsWith(".txt");
		    }
		});
	for (int i = 0; i < textFileNames.length; ++i) {
	    File oldFile =
		new File(textFileNames[i]);
	    File newFile =
		new File(textFileNames[i].
			 substring(0,
				   textFileNames[i].length() - 4) +
			 ".xml");
	    oldFile.renameTo(newFile);
	}
    }
}

I've just had to deal with an error caused by improper java serialization and deserialization. I thought I'd document it so that I don't forget.

An instance of a non-static inner class in Java has a hidden reference to the instance of the outer class that contains it. This reference is used when accessing members of the outer class. By getting the serialization wrong I was able to create an instance of an inner class that didn't know what it's outer class instance was. This leads to a NullPointerException when accessing members of the outer class. If the method called is private the message at least gives a hint of the problem, if it's not then the whole thing is pretty confusing.

To start with here's a very basic Java program that creates an instance of a class Outer1 that includes a reference to an instance of an inner class Inner1. This is then serialized and deserialized. If you compile and execute the program you get.

bash-2.05b$ java -cp . Outer1
Before
printString(outerField)
printString(innerField)
After
printString(outerField)
printString(innerField)

Say I want to implement my own serialization and deserialization for the inner class. All I need to do is add writeObject and readObject methods like this.

	private void writeObject(ObjectOutputStream oos)
	    throws IOException {
	    oos.writeObject(innerField);
	}

	private void readObject(ObjectInputStream ois)
	    throws IOException, ClassNotFoundException {
	    innerField = (String)ois.readObject();
	}

Notice that I don't call the defaultWriteObject and defaultReadObject methods on the ObjectOutputStream and ObjectInputStream. After all, my class is a direct subclass of Object and I'm handling all of its fields myself. Here's the modified program but when I run it I get a NullPointerException. Here are the messages

bash-2.05b$ java -cp . Outer2
Before
printString(outerField)
printString(innerField)
After
printString(outerField)
java.lang.NullPointerException
	at Outer2.access$100(Outer2.java:9)
	at Outer2$Inner2.output(Outer2.java:30)
	at Outer2.output(Outer2.java:17)
	at Outer2.main(Outer2.java:66)

If printString(String s) is made public the messages are even more cryptic.

bash-2.05b$ java -cp . Outer2
Before
printString(outerField)
printString(innerField)
After
printString(outerField)
java.lang.NullPointerException
	at Outer2$Inner2.output(Outer2.java:30)
	at Outer2.output(Outer2.java:17)
	at Outer2.main(Outer2.java:66)

Note that Outer2.java:30 is printString(innerField); and Outer2.java:9 is public class Outer2. The problem is that while on line Outer2.java:17 the instance of Outer2 is able to call the output() method on the Inner2 instance (inner.output();) that inner code instance is unable to call the printString(String s) on the Outer2 instance.

And why is this? It's because I didn't call defaultWriteObject() and defaultReadObject(). As well as the user defined fields in a class these methods also take care of, for an inner class, the reference to the enclosing outer class instance. Modifying the writeObject and readObject methods as below cures the problem.

	private void writeObject(ObjectOutputStream oos)
	    throws IOException {
	    oos.defaultWriteObject();
	    oos.writeObject(innerField);
	}

	private void readObject(ObjectInputStream ois)
	    throws IOException, ClassNotFoundException {
	    ois.defaultReadObject();
	    innerField = (String)ois.readObject();
	}

This version of the program runs correctly and produces:

bash-2.05b$ java -cp . Outer3
Before
printString(outerField)
printString(innerField)
After
printString(outerField)
printString(innerField)

Log4j is an excellent logging package for Java. I've been using it since version 0.7.4 in early 2000 and we use it at work for all our logging. Presenting the information below may seem to many log4j users like teaching your grandmother to suck eggs but I think it's useful so I though I'd write it down.

Log4j's free documentation is good for describing the various configuration and logging choices you can make but doesn't present any task based or how-to information. This note describes a simple log4j setup that uses four files to record debug, informational, warning and error messages. The debug file will contain all messages, the informational file only informational, warning and error messages, the warning file only warnings, and errors and the error file only errors.

In each Java source file I define a private static final Logger instance and use that for logging. Using the class the logger is in as the value for the getLogger method means each class gets it's own Logger instance, and the logger hierarchy parallels the class hierarchy. This gives you good information about where messages are coming from and good control over which ones are logged. So in a class called Test I'd use:

private static final Logger log =
    Logger.getLogger(Test.class);

When logging a debug or info message it's good practice to preceed each with a test using the isDebugEnabled or isInfoEnabled method. This will save you cycles later when debug or info messages are disabled, especially if the message being logged includes objects that are expesive to compute. For example:

	if (log.isDebugEnabled())
	    log.debug("A Debug Message");

In the log4j configuration file the first stage is to define four appenders, one for each output file. If this file is named log4j.xml and is on the classpath then it is found automatically by log4j when it is needed. Use the threshold parameter to limit the messages that are written to the file. As threshold is a property of the AppenderSkeleton class the same technique should work for any appender. Here's the definition of the DEBUG appender.

<appender name="DEBUG" class="org.apache.log4j.FileAppender">
  <param name="File" value="logs/debug.log" />
  <param name="Threshold" value="DEBUG" />
  <layout class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern"
	value="%d{ISO8601} %-5p %c - %m%n"/>
  </layout>
</appender>

After all of the appenders the lowest level logger to be controlled is defined. It is associated with all four appenders so that all messages sent to the logger are presented to all appenders. As explained in the log4j manual appenders are additive Each enabled logging request for a given logger will be forwarded to all the appenders in that logger as well as the appenders higher in the hierarchy. So the single logger definition below will see messages logged by any loggers in the com.zanthan hierarchy.

<logger name="com.zanthan">
  <level value="debug"/>
  <appender-ref ref="DEBUG"/>
  <appender-ref ref="INFO"/>
  <appender-ref ref="WARN"/>
  <appender-ref ref="ERROR"/>
</logger>

You can turn on or off logging of various levels by class or package by adding extra logger entries. For example the entry below will meant that classes whose names start with com.zanthan.xsltxt will only output warning and error messages.

<logger name="com.zanthan.xsltxt">
  <level value="warn"/>
</logger>

By bob mcwhirter of The Werken Company. Very interesting stuff. I've used jaxen and saxpath and been very impressed.

I work on a commercial Business Process Management tool so was interested to read about werkflow and drools. Not quite the same target though.

My comments on this O'Reilly weblog entry. O'Reilly Network: Has Java passed its prime? [October 01, 2002]

Increasing complexity, whether real or just perceived, does present a problem for Java as it may prevent some people from starting to use it. In some areas it's likely that Java will be replaced by simpler languages that offer other benefits to their users in those niches. In time one of these may emerge from its niche to challenge Java in the mainstream, but I don't think that's going to happen very soon.

In Java the perceived complexity comes from more packages and APIs being added to the standard set. The language itself has changed very little though, the complexity is in the number of packages.

The complexity arises for a reason though. Java is used to try to solve an increasingly diverse range of increasingly complex problems. Any language used in this way requires more complex functionality, look at C#, perl, python etc. If a language can solve a wide range of problems then it's likely to be seen be some people as "complex".

Complexity has its benefits too. There is now so much Java code available, in the standard packages and from open source projects, that many programming problems can be solved by assembling a solution from already working code. This benefit, often claimed for perl with its huge CPAN repository, really is quite substantial. However, it only occurs when a language reaches some critical mass, which is very close to the point at which people start to declare it's become too complex!

Finally, Java really should have no existence outside of the benefits it provides to its users, if it is replaced by a better solution then that's good. It's like the lamp in the new IKEA adverts, why feel sorry for Java, it has no feelings.

Inspired by Jamie Zawinski's WebCollage perl program I've implemented something similar, though not as impressive functionally, in Java. An example of the output is here.

It's structured as a three stage processing pipeline hooked together using property listeners. The stages are:

• An image source. This chooses a number of images to create a collage from. It has an images property that changes when it makes a new set of images available.
• A collage creator. This waits for changes to the image source's images property and converts the images into a collage. When the collage is ready the collage creator's collage property changes.
• One or more collage receivers. These take collages and display them or save them as files. They listen for changes to the collage property of the collage creator.

Currently I've implemented two image sources. They both read images from a directory. One produces a single set of images, the other produces images every n seconds. I intend to write an image source that chooses random images from web pages, using Google as a search engine to select them.

There are three collage receivers. One displays the collage in a window, one saves the collage as a png file, overwriting the previous contents, and the last saves the image as a png file under a unique name in a directory.

The algorithm for producing the collage is currently fairly simple. It starts with a list containing an initial rectangular area the size of the collage to be produced. An image is randomly drawn somewhere in the rectangle with the clip area set so that it does not spill too far outside the rectangle and blending used to combine it with the background. The remaining area is then divided into rectangles by walking clockwise round the image. The original area is removed from the area list and the new rectangles added. Then the largest area in the list is chosen and the process repeated until the list is empty. I'm thinking about attempting to rotate some images in the future, as this might make the collages look less blocky, though it will make the calculation of the remaining areas more difficult.

As the code uses java.awt.Toolkit to load images it needs some sort of display to work. This presents a problem for headless unix systems. I'm going to test using Xvfb in this situation. An executable jar file is here, use java -jar collage.jar, and the source is here. If you use java -jar collage.jar --help you should get some help on the options.

Just a reminder to myself to try Piccolo XML Parser for Java sometime.

Some comments on O'Reilly Network: Another Take on Swing and Java's Success. I'm the "one of the reader comments" mentioned at the top of the article for my remarks at the bottom of O'Reilly Network: The Success of Java.

I agree that having a common GUI api for both desktop and web work is doable. After all Microsoft seems to have almost done it. However, I don't think that starting with Swing is necessarily the best idea, it's too complex.

In my opinion the first thing is to decide on the sort of app that's being targeted. Swing lets you build pretty much anything and has functionality, like the paint method, that would be very difficult to implement in a web setting. If the focus is tightened to just "business style" apps then the problem is more tractable. Maybe the system should be built from the other end, would it be possible to implement the struts api on the client?

With struts the biggest problem for client implementation is the use of HTML for the views. This would have to be changed. Here XUL could be useful for describing an abstract layout which would be used to autogenerate appropriate HTML and Swing layouts. Some sort of overriding scheme to allow replacement or enhancement of the generated UI would have to be provided, you can never always generate exactly what's wanted. Fortunately CSS should provide nearly all of the look and feel customization needed for HTML, and for Java suitable overrides of the generated code by subclasses could let the developer tune the appearance.

The ultimate would be to come up with a way to allow the client app to take advantage of the increased capabilities that reduced latency and so greater interactivity gives it. How can the two models of interaction, screen at a time vs field by field, be reconciled, or at least accomodated in a single framework.

I agree with Marc that GUI framework development requires the internal and external consistency that best comes from a strong focus. For most open source or free software projects this is most often best provided by a strong leader. Especially in projects where there is the perception that this is a chance to build a better mousetrap it's important to have some way to ensure that people are all working towards the same mousetrap.

Following a suggestion from Troy Bridoux I've changed the tag line for XSLTXT so that hopefully:

• it's clearer what XSLTXT is
• it sounds less intimidating

It now reads XSLTXT - the XSLT compact form. Perhaps now more people will find the package, and find it useful.

Interesting article on the BEA developer's site discussing when to use JCA and when to use WebServices. A nice counterpoint to the WebServices everywhere and for everything bandwagon.

Last year I made some simple performance measurements to see whether it was faster when scanning the characters in a string to use s.charAt(k) == 'x' or to first convert to an array of char and use c[k] == 'x'. Obviously this is in no way a general performance test, I just did it because I wanted to try and optimize some heavily run code.

Anyway, the results first. I used open office to plot the graph. The y axis shows the time in milliseconds to scan a string 50,000 times. It's the average of 50 runs. The x axis shows the length in characters of the string being scanned. The legend at the bottom shows the method used (toChar or charAt), the java version (131 or 140) and whether the -server or -hotspot (S or H) flag was supplied.

Using the -server flag made the biggest difference in the tests. For strings over 25 characters in length it provides the greatest speed. Apart from a strange bump for string lengths between 10 and 25 characters, which persists when I rerun the tests, the fastest technique is -server, using charAt, and running 131. On the other hand the slowest was -hotspot, using charAt, and running 131. Changing version to 140 improved things quite a bit.

With version 131, when using -hotspot, it used to be worth using charAt for short strings, under about 8 characters in length, and switching to toChar for longer strings. With version 140 that point has now moved out to around 75 characters. If you're using the -server flag, which most java code does, it's always faster to use charAt.

If you're interested in running the tests yourself the java code's here.

An article from an O'Reilly columnist talking about The Death of EJB As We Know It? Personally I don't think things are that bad.

The principles for building distributed systems, for transaction handling, etc. have been understood for longer than EJB has been around. And they've been difficult for longer than EJB has been around. Some things are just conceptually hard, and it's not possible to make them easy. On the other hand the fact that something that is conceptually hard does not also require that it is difficult to implement. Choosing the correct transaction boundaries for your transactions so as to get the best performance with the fewest deadlocks bearing in mind the business requirements for consistency is difficult. But it shouldn't require procedural code to implement, you should be able to declare what you want. J2EE get's this right. The deployment descriptors make a lot of this stuff declarative, but you still need to know what you're doing, and you probably always will.

I think in many places we're all still programming at too low a level though. I shouldn't have to use procedural code to define the persistent fields for an object, or set up the mapping to and from a persistent data store. I know that there are IDEs out there that do this visually. OptimalJ from Compuware is one of these. You define the model, the patterns to use, etc. and the code is generated for you. My issue with these systems is the vendor lock in and the cost of the tools. I might as well use .NET if I'm going to be tied to one vendor.

I'd like a more open system. Something along the lines of multiple layers of domain specific languages, each generating a more detailed description of the system in the next more detailed language, perhaps in combination with other descriptions of other aspects, till you get to executable code. At each level it would be possible to override the generated code giving you the opportunity to customize at the appropriate level of abstraction. The "compilers" converting the system expressed in one language to a more detailed expression in the next language would also be modifiable, perhaps through templating. I prefer this to the idea of adding annotations to the simple model to express the more complex concepts as I'd like to keep the levels of abstraction separated as far as possible.

Of course ideas are cheap compared to implementations, and as this idea doesn't have an implementation it's not worth a lot at the moment. Also, it rambles too much. Need to tidy up and try to express better what the idea is.

I found this report on the USENIX JVM Symposium, 2002, not that anyone was hiding it, on the O'Reilly Network: Weblogs page. The actual webpage for the proceedings is here. Unfortunately I'm not a member so I can't read the papers, a shame as some look very interesting.

The slides for the keynote are online though and their title, "Stop Thinking Outside the Box. There Is No Box.", reminds me of a similar, though I think more forceful, remark that I recently read. If you always have to think outside the box maybe the box is too small. What I take from that is that if you always have to work round, or outside, a broken, or narrow set of constraints or procedures perhaps you should address that larger problem and fix the process as well as solve the immediate problem.

From LtU some interesting points about the 10 Reasons We Need Java 3.0 article. A different point of view than the slashdot stuff and with comments from people who understand a wider range of language models. Also there is this thread on TheServerSide.com. It includes a link to this page that talks about boxing and unboxing primitive values from a C# FAQ.

An article from Elliotte Rusty Harold called ONJava.com: 10 Reasons We Need Java 3.0. I tend to agree with most of the posters in this Slashdot discussion about the article, I think it's a rather shallow list. He picks on a number of motes while ignoring the planks. The ones from his list I'd like to see are

• Eliminate primitive data types (Elliotte's 8), or perhaps add automatic wrapping and unwrapping.
• Extend chars to four bytes (Elliotte's 7) looks like a good plan based on the information he provides.
• Redesign class loading (Elliotte's 1). I don't find the system as confusing as he seems to but I think it would be nice to incorporate versioning in the same way that the .Net CLR does.

Plus two extra.

• Add generics. I hope this is probably the one that most professional Java programmers would most like to have.
• Tail call elimination.

I'm not sure these need Java 3.0 that isn't backwards compatible though. I'd hope it would be possible to make these changes within the current language. The existing code base is a great asset of Java and shouldn't be thrown away. That would just take us back to where .Net is now.

TheServerSide.com has an intresting article called Implementing a Data Cache using Readers And Writers. However, it includes the following piece of code

public class MyLock {
  static ReadWriteLock myLock;
  public static ReadWriteLock getLock()
  {
    if(myLock == null)
    {
      synchronized (MyLock.class) 
      {
        if(myLock == null)
        {
          myLock = new WriterPreferenceReadWriteLock();
        }
      }
    }
    return myLock;
  }
}

This is an example of "Double-Checked Locking", a technique meant to save the cost of a synchronization when it's not needed. The problem is that Double-Checked Locking is Broken. For the particular situation shown an easy fix is

public class MyLock {
  static ReadWriteLock myLock = new WriterPreferenceReadWriteLock();
  public static ReadWriteLock getLock() {
       return myLock;
  }
}

Lots of fun from IBM, words I never thought I'd write. They've released a lovely Java "learning" environment called robocode. The idea is you're introduced to Java by programming a little robot tank to attack and destroy other little robot tanks. I don't know about the learning part but it's great fun to play with. I'll get that little SpinBot one of these days.

I saw prevayler on sweetcode a while back and thought it was interesting then. I'm currently thinking about how to implement a persistence system for a simple application I want to write and the ideas behind prevayler, if not the actual code, might be the way to go.

Instead of using a database or other persistent backing store all business objects are kept in memory all the time. A regular snapshot is taken, using Java serialization, to provide a point to recover from. Between snapshots all commands that modify the data are recorded as serializable Java objects in a log file. If a crash occurs the snapshot is restored and the log used to roll forward by reapplying the commands. Provided you have enough memory to hold your complete object graph its a very easy system to use, and, according to the figures provided on the site, a very fast one.

You've all probably seen this one before but I find it useful during forensic investigation of programs. The general situation is

• You're working on a large mass of code you understand poorely.
• You can see where the problem is being manifested, generally because you can see where an Exception is being thrown from.
• The underlying cause is that some other method is earlier called with an incorrect value, and you can find that method.
• You don't know the program flow well enough to know where this earlier method is called from, and that's where you want to look for the fundamental problem.

Fortunately you can use an Exception to generate a stack trace without having to throw the Exception.

if ((prefix != null) && prefix.equals("xmlns")) {
    Exception e = new Exception();
    StringWriter sw = new StringWriter();
    PrintWriter pw = new PrintWriter(sw);
    e.printStackTrace(pw);
    pw.flush();
    log.debug("getNamespaceURI(...) called from " +
              sw.toString());
}

I've seen various posting about this message on newsgroups and the web. Where I've seen it in anger is when using jdbc. People worry about forgetting to close a connection after using it so they place a close() call in a finalize() method in the wrapper around the connection. The thinking is that when the wrapper is garbage collected the close() will be invoked and the connection cleaned up. I've seen this is shipping commercial code. Unfortunately it doesn't quite work like that...

The problem is that the finalize() methods for the fields of a java object are called before the finalize() method of the containing class. By the time finalize() is called on a connection wrapper the wrapped connection has already had it's finalize() method called and the socket is already closed. This will directly cause the "Descriptor not a socket" error. From this point of view the finalization method is fairly useless for what is often recommended for, cleaning up resources, if those resources are anything other than the most simple cases. Certainly you may have to investigate whether the members of your class already have finalize() methods when considering how to implement one in the containing class.

I've recently spent some time dealing with a java.lang.VerifyError exception that turned out to be due to a simple typo. In the interests of helping others, and revealing my own bad typing, I'm posting the results here.

Here's a simple class that demonstrates the problem. The one I originally found it in was more complex and it took me a while to track down the simple mistake.

public class Test {

    public static void main(String[] args) {

        for (int i = 1; i < 3; ++i) {
            System.out.println("2 i = " + i);
        }
    }
}

If you compile and run it it simply prints

2 i = 1
2 i = 2

Now what happens if you make a typo and put for (int i = i... instead of for (int i = i..? Well, you get a compile error just like you should.

Test.java:5: variable i might not have been initialized
        for (int i = i; i < 3; ++i) {
                     ^
1 error

But if you have another variable called i referenced before this one the code compiles correctly. So, the program below will compile even though it also makes reference to an uninitialized variable as the two variables called i are different variables.

public class Test {

    public static void main(String[] args) {

        for (int i = 1; i < 3; ++i) {
            System.out.println("1 i = " + i);
        }
        for (int i = i; i < 3; ++i) {
            System.out.println("2 i = " + i);
        }
    }
}

However, when you try and execute the code you get this error message.

Exception in thread "main" java.lang.VerifyError: (class: Test, method: main sig
nature: ([Ljava/lang/String;)V) Accessing value from uninitialized register 2

It took me some time to go from this message to the actual problem. In my defense I'd like to say that the actual code also includes a whole bunch of XML and JDBC processing and was trying to access a database though a JDBC connection provided by Weblogic. With all of the third party jar files that had to be present for compiling and running I was sure for a while that it was some version mismatch somewhere.

XML parsing is generally regarded as slow. However, if you need to, or have to, store XML in a database it is certainly faster to store the XML as a string and then parse it than to store the Java serialized representation of a JDOM. From tests I've run parsing and constructing a JDOM structure is from 1.5 to 2 times as fast as deserializing the same structure. The larger the XML document the bigger the difference. The XML representation is also only 30% of the size of the serialized representation.

Some work I've been doing recently has made me wonder, what is the fastest way to check each character in a Java string for some property? The two possibilities are

• Convert the string to a char array (toCharArray) and loop over the array.
• Loop over the string and use the charAt string method

If you choose to convert to a char array then you have to "pay" to create the array, on the other hand if you use charAt then the index you pass in is compared to the string length to make sure it's not out of range on every call. I wrote a quick program to measure the time taken for both techniques and for strings greater than 10 characters in length it is always faster to convert to a char array.

When you look at strings between 1 and 10 characters in length using charAt starts off being faster, with using a char array overtaking it when the string gets to 8 characters in length. For the actual application I think I'll use both techniques and switch from charAt to using a char array when the string to be scanned is 8 or more characters long. As the length is needed for the for loop anyway the only extra code is a simple if test.

The other question is "Is this really worthwhile?". Well, in this case I think it is as the code that performs this scan is currently taking 3.9% (the hottest hot spot) of the application/s time. At least I'm not commiting the "premature optimization" sin :)

If you're looking for the homepages for these two projects I should have them setup by Monday 25th. Until then there are some postings about XSLTXT somewhere around here and the complete code for jxminor, including comments, which is the only doc available at the moment, is checked in to savannah.

What do you do about checked exceptions that you know will never be thrown? One possibility is to just use an empty catch block but there is a better way.

The empty catch block technique would be something like the code below with a little comment to indicate that the exception is being ignored for a good reason.

try {
    methodCall(param);
} catch (ExceptionThatIsNeverThrown e) {
    // ignore as this will never happen
}

The nicer alternative is to create a subclass of java.lang.RuntimeException, perhaps called UnexpectedException, that can be used to wrap the exception that is caught and rethrow the UnexpectedException instance. A RuntimeException subclass must be used as your code may be in a method to which you can't add any more checked exceptions (usually because the method it overrides has a limited set that it throws and you can not add to that set.)

try {
    methodCall(param);
} catch (ExceptionThatIsNeverThrown e) {
    throw new UnexpectedException(e);
}

This way if the exception that will never occurs does occur at least you find out about it instead of having the program fail later for some other reason that is very difficult to trace back to the root cause.

The javadoc for java.io.BufferedReader says It is therefore advisable to wrap a BufferedReader around any Reader whose read() operations may be co