Week 37 of 2009

Java SE 6 executable Jar files don't seem to be limited to 64M on Vista x64 which means that running OOA Tool by clicking the Jar is probably better in the next release than running the Batch or Shell scripts that I also include in releases since event logging is now captured and viewable within OOA Tool. After some checking via Google, I discovered that executable Jar files can be executed with any JVM options by altering the following registry entry on Windows:

HKEY_CLASSES_ROOT\jarfile\shell\open\command

The current value on my machine is:

"C:\Program Files\Java\jre6\bin\javaw.exe" -jar "%1" %*

Changing this to the following increases maximum memory to 256M:

"C:\Program Files\Java\jre6\bin\javaw.exe" -Xmx256M -jar "%1" %*

However, this step doesn't seem to be necessary on Vista x64 since OOA Tool starts up with 903M by default on my machine! I'm not sure what you need to change to do the same thing on a Mac or under Unix.

My JBuilder 2005 IDE finally seems to be having problems building OOA Tool by itself. I have already had to work around some nasty JBuilder bugs, e.g. you can't break or continue directly out of a nested loop since JBuilder generates some shit bytecode that doesn't work. Note that all releases are built using an Ant build file and the latest JDK so these problems only effect me since I want to be able to instrument and step thru code using the JBuilder debugger. The latest problem seems to be related to too much complexity involving Java Generics. The JDK builds all of my stuff without a single warning (although I do have to use a few @SuppressWarnings("unchecked") directives). I can even build my stuff using JBuilder itself if I build all packages bar one first and then build the last package afterwards!

I have considered upgrading JBuilder to the latest version except they have moved JBuilder onto the Eclipse platform which means I will have to learn the Eclipse IDE to use it. If I'm going to learn Eclipse I don't see what additional benefits I would get from buying JBuilder since I'm not currently a Java Enterprise user. I also don't use JBuilder's GUI builder. If Embarcadero Technologies wants users like me to move to the latest version then they need to make the Professional version of the tool cheaper or they need to provide a Foundation version for free like they did in the past.

I mentioned Vista for the first time at the beginning of this blog because I have recently bought a new laptop (my old laptop kept overheating and shutting down). It's the first machine I have had with Vista, previous machines have all been running XP instead. It's also the first 64 bit machine I have had so I can now see how well Java x64 runs. There doesn't seem to be any problems running OOA Tool. A screenshot from my laptop is shown below:

From the screenshot, you can see that load times are longer in the latest build. This is a consequence of a safer model element design and the fact that I haven't spent any time optimizing load times yet. Most users will not need to load more than one project on startup so load times should not be more than a few seconds anyway.

One big drawback with Vista is that I can't get JBuilder 2005 to even install never mind run. I've tried copying the installed directory over from my desktop machine (as recommended by other developers in my position) but it still doesn't run. It looks like I will have to move to Eclipse once my desktop machine packs in.

OK, so what have I been doing other than messing with Vista and JBuilder this week? I have spent most of the week refactoring an application wide factory into OOA Tool. The existing design included two types of factory: model element factory methods which are defined on parent model elements (e.g. OOAObject class defines a createAttribute() method), and editor view factory methods which create an appropriate form/diagram/table/report view for a given model element. To debug OOA Tool I often have to tweek methods in various model elements to determine what's happening. I also have to add workarounds for backwards compatility. However, I really want to be able to subclass model elements when debugging and move any backwards compatibility code out of the main model element classes into subclasses. To do this with the current design requires subclassing at several levels, e.g. to create a new Attribute subclass we need to create new OOAObject, InformationModel, Domain and Project classes since creation is delegated at each level.

The solution on the model element side was to add a factory reference to all model elements. Root elements are passed a factory but have no parent. Non-root elements are passed a parent and optionally passed a factory. If no factory is given then a non-root element uses the factory of the parent. I also wanted to statically scope factories using Generics so the new signature of the ModelElement class is given below along with a brief outline of OOAObject:

public interface ModelElementFactory { }

public abstract class ModelElement<F extends ModelElementFactory,
                                   P extends ModelElement<F, ?> {
    private F m_factory;

    protected ModelElement(P parent, F factory, boolean deleted) {
        if (factory == null) {
            throw new NullPointerException("Factory required");
        }
        // ...
    }

    protected ModelElement(F factory) { // Root element constructor
        this(null, factory, false);
    }

    protected ModelElement(P parent) { // Non-root constructor
        this(parent, (parent != null) ? parent.getFactory() : null,
             true);
    }

    public final F getFactory() {
        return m_factory;
    }
}

public interface OOAFactory extends ModelElementFactory {
    public Attribute createAttribute(OOAObject parent);
}

public class OOAObject<F extends OOAFactory>
        extends ModelElement<F, InformationModel<F>> {
    public OOAObject(InformationModel<F> parent) {
        super(parent);
    }

    public Attribute createAttribute() {
        return getFactory().createAttribute(this);
    }
}

I'll leave this weeks report there since we seem to be getting a little bit technical with all this Java coding! Hopefully, I'll have more modelling specific stuff to report next week.