Ancient Programming

What I encounter in my software part of life is in danger of being commented upon here

Archive for March, 2008

fixedformat4j api - bring on your feedback!

Posted by Jacob von Eyben on 17th March 2008

Earlier I wrote about reading and writing fixed formatted text files. Fortunately you all were eager to comment and provide suggestions on how to do this.
Inspired by your suggestions I decided to write an open source api to manipulate these fixed formatted data and promised to get back when I had code that was releasable.

That time is now!

I have deliberately not released a version yet as I would like some feedback before I commit myself to an api.

Please take a look at the documentation at and let me know your thoughts on the api.

The sourcecode can be browsed here.

I hope you will bring me some feedback before I do a final release.

Posted in fixedformat4j, java | 9 Comments »

Best practise when handling tags and branches (using subversion)

Posted by Jacob von Eyben on 15th March 2008

This is the way I prefer tagging and branching my code when developing and releasing software. I use subversion but the overall guidelines can be applied by any versioning tool - say CVS.
I assume that you keep your source in the recommended structure:

  • trunk
  • tags
  • branches


Always use three digits to denote a release: major.minor.bugfix. ex: 1.2.0.

Name your trunk code like this: major.minor-SNAPSHOT, where major.minor denotes the next version to release. ex: The version in production is 1.2.0, you should name the trunk version 1.3-SNAPSHOT. I use snapshot to tell others that such a version is an arbitrary build along the way to a stable 1.3 release (The name ’snapshot’ is inherited from maven).


When releasing your code, you should tag the version you release by the version. This gives you a chance to always branch from that specific release if a bugfix is required. Ex: you 1.3-SNAPSHOT is ready to go into production. Tag a version by the name 1.3.0.
Even though some versioning tools allow you to commit to a tag, you should not do so. Tags is an image of the sourcecode at the release time!

At the same time you should change your trunk version t0 1.4-SNAPSHOT.


If your newly created release contains a bug that can’t wait to be fixed until your next trunk release, you should create a branch. Do so from your release tag.

You should name your branch like this: major_minor_bugfix, where major and minor is the same as the software in production. Ex: 1_3_bugfix.


I do not recommend having unmerged code on your branch for to long.
I suggest you you merge your software back to trunk for each fix you do. At least you should merge your branch back to trunk when your release a new version.

To assist you in this I suggest your commit message tells what revisions that is involved, - The revision from the branch and the revision on trunk.

Subversion commands

The following is the commands to use in subversion. I assume you use ssh to access subversion and the subversion repository is located at in the directory /var/subversion:

Tagging in subversion

$ svn copy svn+ssh:// \

Branching in subversion

Similar to tagging except the path.

$ svn copy svn+ssh:// \


I will split this into two cases. The case where you merge from the branch the first time and the following merges.

First merge from a branch

First you want to know what revision you are to merge from.That is the revision your branch was created at. You find that revision by executing the following command in your branch checkout:

$ svn log –stop-on-copy

That will list all your changes created on your branch since it was created. You can see the revision where your branch where created in the log output.

Knowing the revision you are ready to merge your changes. Change to a working copy of your trunk code and make sure your checkout is up to date by executing and findout the revision to merge into:

$ svn up

This will update your trunk copy and output the revision you are to merge into.
Now merge the changes by using the following command on your trunk working copy:

$ svn merge -r rev1:rev2 \

where rev1 equals the revision your branch was created and rev2 equals the revision on your trunk working copy.

Fix any conficts and commit your code. It is important that your commit message contains the to revisions you merged. I suggest you write the following. That message is important in later merges:

$ svn commit -m ‘Merged branches/1.0-bugfix rev1:rev2′

Following merges from branch

The next time you would like to merge, you execute the following in your working copy of your trunk code to find the revision to merge from:

$ svn log | grep -i merge

This assume that your commit message when merging contains the text merge - as we did in the first case.
The revision to use is the revision you merged into the last time +1.

Ex your log message looks something like this: ‘Merged project/brances/1_2_bugfix r1631:r1682 into head’, the revision to use is 1683.

With that version just repeat the steps from the ‘First merge from a branch’.

I suggest you read here to find more about branching and merging in subversion.

Posted in how to, subversion | 6 Comments »

Manipulating fixed formatted text files

Posted by Jacob von Eyben on 1st March 2008

I am working on a project where we need to manipulate fixed formatted text files. The fixed formatted files are used as protocol for interchanging data between some legacy mainframe systems. I have been looking for some already existing api for manipulating these fixed formatted data but couldn’t find any.

So this weekend I started implementing a solution based on some of the idea┬┤s we got along the way.


I have a few goals for the api:

  1. A line of text should be easily manipulated as a java object.
  2. Should require a minimum of own code to manipulate the text string.
  3. Use annotations to define attributes like:
    • Offset in text
    • The fixed length of the text
    • padding direction and padding character

The api usage could look something like this:

public interface Record {

  // use if you need a reference to the manipulated string - could be a constructor
  void initialize(StringBuffer buffer);

  // use if you don't need a reference to the manipulated string - could be a constructor
  void initialize(String string);

  String export(); //export string
public abstract class MyRecord implements Record {

  @FixedFormatField(offset = 10, length=20, paddingChar='0')
  public abstract void setMyInteger(Integer myInteger);

  @FixedFormatField(offset = 10, length=20, paddingChar='0')
  public abstract Integer getMyInteger();

And then a factory to create instances of the Record. Maybe annotations on fields would be nice as well as dublicating annotations for setter/getter is waste and could be error-prone.

This is the part I am working on at the moment and getting some hands-on experience with javassist. I will get back to that in another post.


I have named the api fixedformat4j and I will opensource it as soon as I have something worth for others to use. Hopefully it won’t end up as one of my numerous 23% finished projects…

Posted in fixedformat4j, java | 6 Comments »

My own domain

Posted by admin on 1st March 2008

I have been using blogspot for almost a year now but now I found the time and energy to move to my own domain. The genre of the content should remain the same :-)

Posted in java | No Comments »