Chaotic Java

Unit testing is cruicial. If there is Anything you can say about the tools you need in order to create a framework, is that creating unit tests is your safety net when you decide to refactor it completely (and any framework, at its first steps, might go through such a thing - Nothing is ever fully designed for a future feature, not even a complete product.)

A few weeks ago I decided to have a major change to the way X2J analysation works, and use moulds and visitors instead of the previous, “everything-in-one-method” way. This change has worked great for me, but it was scary: What if X2J stopped working?

Sure, I could rollback the code - But that would serve to no good as I still needed this type of change. So I started writing tests. They weren’t JUnit tests, but just regular applications running X2J for me to manually check the results with. It worked, as amateur as it was, and I made the switch.

However, today I face another refactoring of code and I know I can’t do the same thing over again. I need some stability to my code. Some red lights to appear when I do something that risked a totally different part of my application. Something that will tell me almost precisely where I broke the code.

This is where JUnits come in, and if you haven’t been using them, you should do so now. I’m going to start creating them, starting this week. Only then will I tend to my refactoring tasks.

From my own experience, an IDE is just not enough to write a framework. I will try to list a few things I feel are cruicial for a safe, fast and productive development of a framework.

These tools are good for any type of projects, but since frameworks are characterised by having a user base of code writers, they will usually feel more comfortable using these tools than other end-users.

On the host

These are things your host should provide you with, or at least allow you to install.

• Source Code Versioning While CVS and Subversion are the most popular ones for open source development, Subversion (commonly known as SVN) is the more advanced one. For me, as a “on-the-road developer”, its main advantage is in allowing remote locking of files.
• Communication Talking with both contributers and users is equally important, as the users provide you the bugs and feature requests which keep a framework rolling and its developers motivated. Such communication can be achieved by either forums or mailing lists, both are equally good. Just remember to be active in whatever choice you make, and to direct your users there for questions.
• Issue Tracking In addition for having a good communication base, the bugs and features requested should be monitored somewhere for future reference. Not all bugs are fixed immediately, and not all features are coded for the next release; Some will have to wait, and going through the mailing list’s or forum’s history is just a waste of time. Issue trackers also give you the ability to assign tasks to other contributers, and to get statistical information about the issues in the system.

On your desktop

These tools might be provided by your IDE, but sometimes the external tools are the best ones. Let the Editor wizard-boys do their thing and others do what they’re good at.

• Code Analysers One of the best features of IntelliJ IDEA is the Code Inspector, which allows your code to be inspected under your own policies to avoid anti-patterns and to refactor your code in a project-scale way. Obviously, it’s not the only one, and products like Hammurapi.
• Runtime Profiling After everything is said and done, your framework is measured by its benchmarks even more than its API. A powerful profiler allows you not only to provide benchmarking information, but to actually determine where your code lacks in efficiency and suggest fixing hints. Examples can be seen in NetBeans Profiler or .
• Unit Testing Testing your framework is cruicial, but having unit testing gives you the calmness many seek. If you can change a piece of code written four months ago without fear that it will break some code somewhere isoteric without raising a lot of red lights, you truly reached Zen. The most prominent framework for unit tests in Java is JUnit, even though most IDEs today have it built-in. The better ones even offer to generate tests for you, to reduce the time required for writing tests.
• Common Build Script Using a common script is useful for having your contributers using a variety of IDEs, and not just a specific one. This should be supported by your IDE, even though executing a build script is usually like executing a Makefile, which is a great benefit for deployment. The de-facto build script for Java is Apache Ant, supported natively by NetBeans and available for import/export by Eclipse and other IDEs. That said, there are other build scripts, such as Maven, which seems to have more features “out of the box”, such as creating a web page with the build’s details - excellent for nightly builds.

I hope it’s not too much - Or too little. Please comment if you feel I forgot something!

Just like with fresh businesses, the most important thing in making your framework known is ‘Location, Location, Location’. Choosing a location is not that simple: The variety is huge, the advantages and disadvantages in each are worthy of deep consideration, and a thought for future growth is required even when choosing that first ground to set roots at.

When considering a host, you need to take some qualities of the host into consideration:

• Promotion Potential Some hosts are more known than others. Some have better promotion capabilities and tools, and these are always worth examining.
• Web page Hosts might provide your framework with hosting space for a web page. The important thing to check is the size of the host, and the type of shell for configuration you’re receiving.
• Version Control The most important thing in a framework’s host is for it to actually have a version control system. However, even in that you have a choice: Between Subversion and classical CVS.
• Issue Tracking Another important feature is issue tracking, which allows you to manage with yourself, or with between other contributers and framework testers/users, the bugs and future features you and your co-developers are working on.
• Language Some hosts are meant to host only frameworks written in a specific language.
• Licenses Some hosts might limit the choice of licenses you may apply to your code. This might be considered as limitation to some, especially if you had a type of license in mind already.

I will go in further detail about the two qualities a host might offer, Promotion Potential and Web Page, and will expand about the rest in a later post to keep you readers at some suspense.

Web Page

It’s sometimes even more important for frameworks, especially those written for free-of-charge use and with an open source license, to have free host for the framework’s web pages. However, this free host does not always mean freedom in the host type you receive.

Some, like Sourceforge, will give you freedom up to the level of receiving shell access. However, limitation in size (100MB) and the relative slowness of their web pages might make some reconsider before using them.

Others, like Codehaus, the hosting is wiki-based (Usually using Atlassian’s Confluence as they provide free license for open source projects and non-profit organizations). Even though Wikis are very flexible, sometimes it is also very limiting.

Another point to check is whether the host provides statistical information about the visits to your web site. Sourceforge is a for it, even though they force you to place their logo in order for statistical information to be gathered (which in truth isn’t that bad).

Promotional Potential

Placing your framework on a projects’ host puts your framework on the map, sort of speak. Knowing where it would receive attention is important.

The more popular your host is, the more promotion it can potentially give your framework. That seems obvious; However, there is a catch: Over-populated hosts might make your project seem like a drop in the water and Sourceforge is a good example for it.

Hosts with smaller amounts of projects, usually having a tighter selection method than Sourceforge’s, have the privilege of placing your framework on the host’s home page. Examples for such could be the Apache Software Foundation or the Codehaus.

A big advantage to smaller hosts is that they provide more exposure not only to outside visitors but to the people hosting their frameworks. This kind of exposure is important; Many times frameworks in the same host start using each other, especially those with a strong community sense.

Another note about Sourceforge is their reward system for more active frameworks by placing them higher in search results and sometimes even in the monthly newsletter. Active projects are measured not only by their code commit but also by their activity in forums, issues being tracked (such as bugs and features) and the download rate of the project.

Some Conclusions

Since most frameworks aren’t mature at their first stages, I would suggest having some “incubation” time in a big, massively-populated host such as Sourceforge as these generally tend to have a more loosen system to accepting new projects. Once the framework gets into beta stages, promoting it by trying to get it into a more selective, yet more community-oriented host, is my preferable way to go.

Also, even not discussed here, using your private blog, code forums and mailing lists you have some influence in, and just word of mouth is always a good way to promote the knowledge about your framework. However, the way it reaches the general public is usually through the common people googling for what your framework should offer, so placing it in a popular place in the first place is one of the most basic things you can do.