Thursday, June 23, 2005

Why a quick reference tool?

To me having a quick reference tool is just a very nice thing when you're programming as you can very quickly get some quick information--often just to jog your memory--and do so without a lot of effort, like waiting for some big program to load, or being forced to follow some template or have some auto-sense shadowing whatever you type.

I got excited about Class Viewer, the prototype, way before I had a SourceForge project, when I thought about the case insensitive search on methods, where I could just put in a bit of a method name, or put in something like "char" to pull out all methods that had "char" in them, whether they took chars or returned chars, or whatever, as I just hadn't seen that yet in other tools.

And javadocs, for some reason, as important as javadocs are, and despite Sun having produced a nice generic framework for accessing javadocs to the method, it can be a pain keeping up with them.

But if you're doing a quick reference, get a method, but are not sure that it's exactly the method you want, don't you want immediately to see the javadocs to clear that up?

Why should it not be a fluid process that follows the developer's needs?

Well, it can be, and that's what you get with Class Viewer.

It encapsulates a special problem space for the Java developer--quickly looking up basic information about a class, searching on methods, and then, if necessary, getting immediately to javadocs, and that's the problem space.

I used two big windows so that you could easily see the methods to one side as a constant, and get results on the other side, as well as get to, if you need them, constructors and fields.

A tool like Class Viewer by making it easy for people to get to javadocs gives developers greater reason to write them and write them well knowing that people are going to be using them, as it's so easy.

So that's a lot of the concept. Ease of use, quickness and functionality are the ideas behind Class Viewer, where it's supposed to be lightweight, useable in a wide variety of areas, without forcing you to have to get a manual to figure out how to use it fully.


Tuesday, June 14, 2005

Class Viewer Basics

Class Viewer is made to be run from the command line, so you can put the ClassViewer.jar in the classpath, or compile the source and put that in the classpath, and run from the command line with something like:

java com.jstevh.viewer.ClassViewer String

which will open up with the class java.lang.String, or you can just use:

java com.jstevh.viewer.ClassViewer

to open up the GUI that I also call a UEI (User Enabling Interface) blank and type in a class name there.

When not ran as an applet, ClassViewerConfig.xml needs to be in the folder from which you are operating, which means you can have the jar file wherever you want, and different ClassViewerConfig.xml files in folders from which you run the program.

For instance, if you are in /home/research/myresearch and you run Class Viewer from there, you'd need a ClassViewerConfig.xml file in that myresearch folder.

If you run Class Viewer as an applet or directly from the executable jar, you won't be able to select your own classes as they won't be in the classpath.

You can double-click on methods in the left big window to do a search on them, which shows up in the "Results" big window to the right, and then you can double-click on a method there to go to javadocs to that method.

To get inherited methods you have to do a search from the search box in the lower right, and double-clicking on them will just bring you to javadocs at the top of the class.

All searches are case insensitive, and the search from the search box is space delimited.


Edited to change packagedirectory.xml to ClassViewerConfig.xml on 7/29/2015, ___JSH

Thursday, June 02, 2005

Considering the GUI

One the things I did deliberately with Class Viewer--which is why open source is such a nice paradigm as you can try new things--is get away from the "File", "Edit", "View" type of menu at the top. So I have "Help" first, and then "Links", and for when it's not in applet mode, "ClassPath".

To me that's just a more natural way for the menu to go, and I like to think that I managed a fairly decent design for a program I long thought of as a prototype.

The design of Class Viewer is meant to lead you to using it intuitively, without needing a lot of instruction or lots of menu items, as you can type in a class, and then just use the the mouse, and get all the way to javadocs to a particular method.

I decided to call it a User Enabling Interface, or UEI.

The way Class Viewer is designed, there just isn't much configuration, and it gets all of its changeable information, like where packages are, or what browser you're using, from packagedirectory.xml, so the program is fairly static.

I like to say that as long as the format for getting javadocs doesn't change, and the Reflections api isn't broken with previous versions, Class Viewer can be used indefinitely, as you can simply change the xml file, which means that I could stop development now, and feel confident that several years from now, Class Viewer could still be used.

My design focus is on an easy to use design that doesn't force me to keep fiddling with things to do something, and which doesn't make me go through a lot of options, as I think a proper design, for a properly encapsulated problem solution, will not require a lot of effort just figuring out how to get it all to work.

If you need a lot of options, I think you need a separate module or another program that might be called by your app (and I'm considering what else to add to Class Viewer where it would call another program), versus forcing people to spend time understanding a particular design.


Saturday, May 28, 2005

Understanding logic

Here's a post where I go "beyond" and talk about logic, which plays a major role in computer development, but I think there are a lot of misconceptions about logic and what it is.

Essentially, a logical statement links a truth to itself.

Easily people are confused on this point possibly because of the way logic is taught, so like if you have something like:

"if A=B, and B=C, then A=C."

And there it appears that you have different things, but if A=B, then does that not mean they are the same? But the letter 'A' is NOT the letter 'B'!!!

What gives?

Well for programmers it's easy because we know about references. The letter 'A' is just a reference to something else, kind of like if you put a yellow sticky note on a car that says, 'A'.

With that sticky note on the car you can say, put A over in that parking lot, or A really needs a new paint job!

But 'A' is not the car.

It's a reference to the car.

If you get confused on that point then you may see contradiction in logic from the start, so it's an essential point, learning about references.

Now let's move on to more advanced topics with some basic truths or axioms about logic itself, and I'll show you how a supposed paradox is handled, just so you can see the effectiveness of the axioms.

And, oh yeah, what's the point?

Well, for developers, understanding logic is crucial for writing programs that are themselves logical, less buggy, and less likely to do weird and bizarre things that confound everyone!


1. Identical sets are identical.

2. Different sets are different.

3. Statements contradicting axioms 1 or 2 are false or malformed.

4. A malformed statement is one for which a conclusion does not follow given its structure.

5. A false statement is one that while structurally correct is not true.

The "structure" I mean has to do with how the sentence is put together.

For instance, the following is a badly structured syllogism:

If x=1, and y=2, then x=y.

The basic structure for the syllogism--the well-formed structure--is,

if a=b, and b=c, then a=c,

and variations on that structure are to be considered malformed.

Notice that with the first given that x does not equal y, the conclusion is false, but the entire statement is malformed so that is secondary.

With the basic axioms established--and notice how simple they are--it's trivial to handle supposed paradoxes which reduce to attacking one of the first two axioms.

For instance, the so-called Russell Paradox reduces to the assertion that a set includes and excludes itself.

Let A be a set that includes itself, and let B be a set that excludes itself.

B is different from A.

Therefore, by axiom 2 any statement that B is A is malformed or false.

Stating that B is A and B is different from A is structurally wrong, so the full statement is malformed.

Notice also that the resolution to the supposed paradox is the well-formed statement:

Consider a set A that includes all sets, except itself, that exclude themselves.

Notice that the axioms prevent that set from including itself, as then you reduce to a set that both includes and excludes itself, against axiom 2 as I explained.

James Harris

Wednesday, May 25, 2005

Release! Class Viewer 2.0b

Maybe this is why I have a blog as I just can't express the emotional high of doing a file release. I don't even quite understand it myself, but when you put up that new release and off it goes, there's just this surge of emotion. Silly? Maybe, but I feel it anyway.

I'm doing a dinky release with out a lot of changes after a recent release because I decided I needed to fix some things that are kind of quirky in 2.0a and finally have the program tell you if it's in applet mode or not.

And the big change is to have Class Viewer default to the top of the list when you end up with a scrollbar, rather than the bottom.

So now, yeah, maybe it's more like a normal program, but what do I do now?

I'll feel happy about the new release for a while and then try to figure out what to do next.


Wednesday, May 11, 2005

XML More Than The Hype

Despite the volume of work with XML it is still underrated and underappreciated at this time as a format that allows a tremendous number of different systems to talk to each other.

Like, in Class Viewer, I use XML to let human beings talk to the system, telling it where to find javadocs, and what packages it should know.

By using XML, the Class Viewer program is actually capable of being used indefinitely, as long as Sun Microsystems doesn't change the format for finding javadocs, or how Java Reflections work.

So it's in a way a perfect app--here today, useable indefinitely.

And that's thanks to XML.


Friday, April 29, 2005

Wonderful JApplet

I'm going to take the chance to just muse a bit, as it is a blog, so I guess I should put up some thoughts. Oh, I'm working on a 2.0b release of Class Viewer, but still haven't got the hang of the GUI design fixes yet, as I'm still working on it, and learning how you do it in Swing, which, unfortunately, doesn't seem intuitive to me.

Until I get that down I can't have the Class Viewer use the Look-and-Feel functionality, which I guess it'd be good to have, so I'm working on it...

Ok, about JApplets, and why I put wonderful in the title, well, notice that Class Viewer is a JApplet, but it's really an application meant for the desktop, so why make it a JApplet as well?

Well, the functionality of Class Viewer works great over the web as well--though I've got work to do in that area--and you can do most of its functionality over the web, so it makes sense to have it web capable, and that means I can just put it on a webpage.

For those who want the full functionality, you can just download it and run it as an application on your machine, and it's all good.

It seems to me that where there's a possibility of web functionality, applications should be applets, or have an applet portion, like, if it's a huge app, so that you can demonstrate some functionality over the web.


Friday, April 15, 2005

Getting back to Swing

One of the areas where I've yet to really update Class Viewer is with the GUI, and I guess it's time to do so, which means I need to get up to speed with Swing and the latest there.

After that it'll be time for another release which I guess I'll call 2.0b, while on the back burner is a future major release that I've code named Phoenix.

It's time to get back to Swing. And notice I resisted the urge to pun.

James Harris

Tuesday, April 12, 2005

Some history

Studying for the Java Certification exam I was writing programs as I studied, and while learning about Reflections I wrote a short program I called, and I worked with it a while as I thought it was neat to be able to look up class information.

Eventually I got to the GUI sections and thought it'd be a good idea to put a viewer so I wrote, and wrote it as a JApplet with main functionality, which I think is just a good way to write applications, as then you can have them capable of acting as applets.

Well I did pass my Java Certification Programmer and went on to other work, but found that I was using my Class Viewer program regularly, and even tried to talk it up to other programmers who were just not that interested. I don't know how that works, but I think it's typical that when you get an idea, it's not so easy to just show it to people you work with, and expect them to adopt it. Or maybe that's just with me.

I tried to figure out various ways to get it out there, and tried talking to some people, but nothing happened. And I just kind of went on to other things.

Well over a year passed when I ended up in a discussion with someone talking about SourceForge, and nope, I hadn't heard of them before then, but this person had presented a project to them. Well it didn't take long before I figured I should check, so I checked and figured that it was just what I needed. So I immediately presented my Class Viewer program and it was accepted.

And that's how I ended up with my own open source project on SourceForge.

More later on what it's like plus some thoughts on what I see as the market for a class viewing program, plus some ideas for the future.

James Harris

Sunday, April 10, 2005

Getting started

Well I decided I needed to create a blog to cover my open source project, but also I'd like to be able to talk about other work of mine, so I title this "Java and Beyond" so that I could.

Right now I'm just creating the blog while I work on a new release, so the program can link back to the blog.

Later I plan on adding more.

Well, I finished most of the coding and uploaded the files to SourceForge. I need to update the project web pages, but I'm kind of tired.

Maybe later.

James Harris