Chaotic Java

If I try to look at the path software made in its lifetime, I’d see that the amount of configuration required to build an application started with none, gradually grew bit by bit as more and more components were starardised until it reaches the state we’re in today, the too much configuration stage.

Quickly peeking at a J2EE application’s configuration file would reveal the horror and meaning of too much configuration. A huge, generally unmaintainable file, which essentially allows for configuration of anything in your application – Only that in practice, it allows almost nothing at all, a result of its size and complexity.

Continue reading »

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!