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.
James
Edited to change packagedirectory.xml to ClassViewerConfig.xml on 7/29/2015, ___JSH
Tuesday, June 14, 2005
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.
James
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.
James
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!
LOGICAL FORMEDNESS AXIOMS
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
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!
LOGICAL FORMEDNESS AXIOMS
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.
James
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.
James
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.
James
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.
James
Subscribe to:
Posts (Atom)