Monday, March 3, 2008

StampJ Editor

The StampJ Editor is an application written in Java for the managing and inventorying my stamp collection. This tool combined my hobby (stamps) with my career (software development) and allows me to utilize a myriad of technologies to solve a practical problem. The application uses many of Java's emerging projects including:

Currently the database is stored in MySQL on my Linux Server, and is accessed using one of the EJB 3.0 JPA providers. Both Hibernate and Toplink Essentials have been tested, but Toplink Essentials is currently the provider of choice due to its smaller footprint (even though it has technical limitations related to join fetches). At some point I will post an article on this. Another interesting feature of the StampJ Editor (which is a Ruby on Rails concept) is automatic upgrade of the database schema and data migration. While some JPA providers like Hibernate can incorporate new columns, new indexes etc. automatically, Toplink Essentials for one does not support this. As well, I had a situation where one column in the database was split out into two separate columns (description became denomination and description). Therefore I plugged in a database migration/upgrade which will check the class registry in the database (I have a table for this) and if the class versions between the database and runtime do not match, it will run any configured migrators to migrate the data. This supports both SQL file updates and migrator classes. Below is an image of the Splash Screen of the application loading:

Currently the following functionality is available:

  • Ability to create/edit/delete Collections, Albums and Countries
  • Ability to create/edit/delete Stamps
  • Define reference Catalogue Numbers (beyond a primary catalogue number thus creating a cross-reference of catalogue information)
  • View image thumbnails and enlarged "full sized" images on mouse-over. Supports both local image loading and URL Connection loading (from a WebServer)
  • Obtain statistics on collection value, number of stamps.
  • Currency conversion between purchased currency, catalogue currency and current local currency.

Functionality planned includes:

  • Generating PDF reports of collection listings
  • A Web-portal for mobile "quick" search and catalogue lookup
  • Richer reports, statistics and better collection "valuation" based on conditions.
  • More META information such as printing method, paper types etc.Current Sample


  • I currently use a database with 25,000 stamp entries as a performance benchmark.
  • The current "live" database has only ~ 800 stamps defined. But it is growing...

There is currently about 400 Junits written to test many sections of the code. Primarily, the Junits test the services behavior with the JPA. I have learned through experience that while writing JPA code is easy, writing JPA code to work in a swing application is not always so easy.

I am interested in collaborating with any interested developers or users of the application. If you are interested on information, contact me at

No comments: