My Top-10 Favorite Development Tools

The other day I got a question about which are my favorite tools, i.e. what is in my Java developer toolbox. I was asked to list my top-10 favorites. This gave me the inspiration to write a blog article on the subject. So here goes my top-10 list of favorite tools.

1. Eclipse
   The basic tool in any Java developers toolbox. The IDE to use.
   
2. Beyond Compare
   This is the best comparison tool that I have ever used. There are some open source comparison tools, but they do not match up against Beyond Compare. I think that Beyond Compare is worth every penny.
   
3. FindBugs
   FindBugs is used for finding bugs or potential bugs in your Java code. I use the plug-in version in Eclipse and use it from Maven as well.
   
4. Microemulator
   An Open Source Java ME emulator. Lets you test your Java ME applications. The drawback is that some JSRs are not implemented yet. Most notably is JSR-205 and JSR-211.
   
5. Virtual Box
   This lets me run Ubuntu Linux inside Windows Vista. No more dual boot configurations.
   
6. Subclipse
   Lets you use Subversion inside Eclipse. The Subversive plug-in is a better tool, but the Subclipse tool works better with the Maven plug-in-
   
7. Tortoise SVN
   Whenver you are in the Windows file explorer it is nice to have access to Subversion. I have set it to use Beyond Compare when doing file comparison.
   
8. Maven
   I did not really like Maven from the beginning. At the time I was a big fan of Ant. Maven contains some functionality that is not available in Ant, such site generation. I
   
9. Eclipse Maven plug-in
   The name speaks for itself, it gives the ability to run Maven from Eclipse. There is also the pom and Doxia editors that are really good.
   
10. Eclipse MTJ plug-in
    The Mobile Tools for Java lets you perform the necessary Java ME tasks.
    

This it is. Do you think that I have missed some tool? Is something on the list that in your opinion that should not be there? Looking forward to her

Using Your Own Stuff Is Good

Using your own stuff is good! Nothing remarkable about that, almost every developer would agree on that. In fact this is how Microlog once was created. It was created out of a real need and I used it extensively from the beginning. As years has gone by, a lot of contributions has been made. The philosophy behind Microlog is that there should many different logging destinations, each suitable in its on special situations. Which logging destination you choose is a matter of taste and the technical circumstances. As a consequence I tend to use a small portion of Microlog, beside the core classes.

The project I am currently involved in has been running for several months before I joined. The initial team has been wise enough to choose Microlog. When I joined the project, Microlog V1.1.1 was used. Yesterday I was given the assignment of logging some low level details, that potentially could create a lot of logging output. To be able to control the logging with fine granularity, I needed the newest and hottest version of Microlog. Its support for hierarchical loggers, makes it possible to set different logging levels on different classes. In my case I wanted to use TRACE for one class, but DEBUG for the rest of the classes. In my own projects, I usually only import the classes that I really need and leave the rest out. In some cases I have used the binary version of Microlog and ProGuard to keep the packaged Microlog classes to a minimum. The current project is different, Maven is used for building. As such it uses a repository for its jar files.

I added Maven code to use the latest version of Microlog snapshot. When I used it on my own computer this worked like a charm, but one of my colleagues complained that he could not perform a build. It was missing a jar file from the Microlog repository. As it turned out, this jar was missing. It was available for Microlog V1.1.1, but not for the latest snapshot build. It was very easy to solve, just copy a directory and the repository was working the way it should.

Other problems emerged when configuring Microlog. The original idea was that the new PropertyConfigurator should be backward compatible, in order to make it easy to upgrade from Microlog 1.x.x to Microlog V2.0. I found one bug; a property name had changed. This was also easy to fix. Another deploy and the repository contained the fix. The other problem is that I have re-structured the packages, which means that all the appenders and formatters properties have changed. The re-structuring is very important, so I plan to keep the new package names. Although they break the backward compatibility. But since I have changed the major version number, I am not obliged to be 100% backward compatible. When writing this, a new idea has popped up in my head. Maybe I should implement a converter that converts from the old property format to the new property format. Is this a good idea? What do you think?