Running Class Viewer

My open source application Class Viewer is meant for Java developers, who presumably want to get the best method to write the best code, so they should have certain skills with Java. And one debate I have had with myself is whether or not I should use a universal installer for downloads. But I think that is more than necessary, as I'll explain how I test download.

I usually download the zip file, but do download the tar-ball file at times to test as well, and unzip it. Then I just double-click on the ClassViewer.jar which will run on many systems as it is an executable jar. Things should be ok at this point as ClassViewerConfig.xml should have unpacked next to the app. The app will give you a little message if it cannot find it! I added the feature that it will also tell you where it is looking for the file.

And if the above works, you can just use it immediately, and I like to use the String class as my test case.

And that is what I do with my test download. It's that easy and that fast. Unpack and double-click on the ClassViewer.jar and try a class.

And the above is just for playing around and seeing that it works! If you use the Firefox browser you can do a search for methods and immediately go to the web to JavaDocs, as Class Viewer will call Firefox out of the box. So don't get surprised if that happens! It's totally normal.

There is where there is an adjustment for your browser, which I don't think is reason enough to bother with an installer. To change your browser, open ClassViewerConfig.xml, where I recommend a text editor, and go to the browser section where you will see Firefox, and change it to your browser! Save, and restart the program. Now it will use your browser.

But for the real work, you'll want a full classpath, and when I run it as described above I don't get one, so the primary way I run to get the full classpath is from the command line.

First you need to unpack the code from the Jar file.

That is done with: jar xf ClassViewer.jar

Then you just use the command: java com.jstevh.viewer.ClassViewer

Or some variant on that theme which of course Java developers, the intended audience would know.

Now the program will have the full classpath.

And that is how you get going immediately. I think an installer is more than necessary, where the one area where plenty of people may change things immediately is with the browser, so why not autodetect the browser? I'm not sure. Sometimes I don't remember why I don't do certain things. If there is any demand for that feature I'd see about adding it.

But going into ClassViewerConfig.xml is important anyway, as you will presumably wish to add more packages including your own. So learning how to do it early shouldn't hurt, and I just use a text editor. Open it up, make some quick changes, save it, and restart Class Viewer and back in business.

If you have any thoughts on the above or suggestions, please comment! Curious about whether others feel like I need to give a different experience for users who download Class Viewer for Java.


James Harris

updated: June 28 2014--changed from packagedirectory.xml to ClassViewerConfig.xml  __JSH

updated: May 20 2017--minor edits to improve visual clarity and emphasis  __JSH

A GUI appeal?

As the years have gone by I've looked at my open source Java project Class Viewer as something of a puzzle to be figured out, as to how I should handle it. And with downloads growing on a year-over-year basis, in over 100 countries, I have decided at least I should give more information for people who are using the application.

So I have been doing posts meant to give more information, like my view that the application is in essence a GUI on Java Reflections API, with quick access to Javadocs. And those were the key features I wanted, and with them I have a tiny application in terms of lines of code, which doesn't in my opinion need many updates. And in eight years I haven't done many.

Since I was a professional software developer at one time, and even was a team lead on a multi-million dollar project, where I was the person who wrote the document for the project for unit testing, I think I should explain even more. For instance I didn't put a unit test framework into the project.

The reality is, I didn't design the project much at all, as it started as test programs for the Java Certification exams.

So refactoring has been on the to-do list for years now, if I ever figured everything out.

And I had already left working as a coder by the time I put it up on SourceForge and had vague ideas of how things might go, like maybe I'd end up with a bunch of other people interested who could polish out the product, but that didn't happen. And it has stayed a single developer project.

Weirdly enough, I've been looking at downloads for years with very little information except a number, like 10 downloads in a particular day, which isn't exactly inspiring. But SourceForge began giving more information like countries, and then it was cool!

Suddenly I found out I had an application with downloads from over 100 countries.

And, um, my attitude began to change.

And I guess it's remarkable that the project has done ok for years with me puzzling about how to proceed with it, and limited development but my theory is that I have a very focused problem space, and most importantly did ok with the graphical user interface aka GUI.

It is built to be as easy as possible with big screens that I want to be intuitive, where you don't need much instruction on how to use it. (I think.)

Rather than focus on a lot of features I was deliberately minimalist, wanting to have only just as many as I thought were necessary, and I just rewrote the top left command bar completely as I just so thoroughly disliked the File, Edit, View format. So I just threw it away. THAT was a lot of fun.

How well did it all work? I don't know. Sure I have growing downloads but not a ton of them, but it's a Java developer tool, so a smaller possible base, but also presumably a very picky one. Still being around after eight years with steadily increasing downloads I think is definitely a plus.

Who knows where things will go from here, but hey, if you want to give me feedback, feel free! It would be helpful. Commenting tools are much better today as the web continues to evolve, and I'm in an assessment phase as I try to figure out where things are with the project.

But in the meantime least I can do is give more information to people who could have been using Class Viewer for years wondering what was going on.


James Harris

Cream colored San Francisco sky

Here's another older photo I found again recently. Taken with my Canon Powershot, December 2008.

North Beach neighborhood

Here's a recent photo taken March 10, 2012. I was intrigued by the sign, but also like the neighborhood which is called North Beach. I was using a smartphone for this picture, a Motorola Droid 2.

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