Defining the Class Viewer project

Back in 2004 I decided to put up on SourceForge an application I called Class Viewer, which is meant to be a tool for Java developers. And I had a very simple set of problems in mind to solve with the application itself.

And it occurs to me that it's a good idea to say what I think the Class Viewer application solves and while I'm sure I've written about it before, I think now is a good time to update a bit, which can include information about updates themselves and how they happen.

To me, Class Viewer is a graphics user interface on top of the Java Reflections API which allows you to easily go to Javadocs as well.

And that's about it.

So it pulls information about a class, and gives you a basic overview including pertinent information like superclass, if there is one, interfaces, and constructors. And even more importantly, it pulls out all public methods and fields, and tries to show them to you nicely, in a way that helps you scan through them easily.

And you can go to Javadocs directly to a method, or just to the class, without much work. For instance, double-clicking on a searched for method in a results window, takes you right to it in Javadocs.

THAT was a big deal to me as while developing I quickly got tired of going out to find Javadocs, figuring out where a class was, getting to that class, and then scrolling down until I found the method I wanted.

And Class Viewer solves those problems for me and did so, yup, back in 2004.

I put it up as I figured it might solve those problems nicely for others.

So in ways, if I had polished out a product back then, there would be little reason for development from then forward! It's a rather closed problem space, with a product that I think handles that problem space.

So why do any further development at all?

The answer has been: I didn't have a completely polished product, I have had a few more ideas around that core problem space, and there have been some shifts within the Java language itself that require updates.

ONE of the remarkable things about Class Viewer is that you could run the very first version I put up, back in 2004, I'm fairly certain and be ok, as you could have downloaded it back then and not had much of a reason to update it since then.

The other reason for development is musing about expanding that problem space so that more than just being a GUI on the Java Reflections API that lets you go to Javadocs easily, it could also turn into a lightweight IDE. And I've done some development that opens that door slightly as I consider that possibility.

But the weird thing is: nearly at the start the project was mostly done.

There is rarely reason for any serious update. And mostly I check to see if any recent changes to the Java language have broken anything.

Some recent updates were more about polishing a few things in my mind, and toying with the idea of moving towards a lightweight IDE. But I can easily go years without any development at all without it being a big deal, which feels a bit odd. I was over a decade ago a lead Java developer at a major software division, and we had lots of iterations. It's kind of odd to control a product that I feel doesn't need them.


James Harris