- Reading the Documentation
- Running the Software
- Building Software
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Running the Software
Many programmers start by giving the project a test drive. Hopefully, it isn't a project for wiping all the files on a disk or sending viruses out to all of your friends, but it may be wise to start with a backup copy anyway, just to preserve the project as you found it. Well-designed software won't let you get into any state that you can't get out of, but you can never be sure that it's all that well designed.
You may not even have an executable copy of the code, in which case you should skip ahead to the next section "Building Software."
The good news is that the executable versions of a project are usually located close to the root-level directory of the project. Look in the root directory, the bin directory, and the samples or example directory.
There are many ways to start a program. If it's a native executable (such as files marked with executable privileges on Linux), you can try just running it from the command line. On Windows platforms, .exe, .bat, and (less commonly these days) .com files run programs. In some ways, executable shell files and .bat files are preferable as places to start, because they usually point out which executable file is the right one, and what parameters should be used. Sometimes the batch file will even be commented. But don't count on it, and don't count on the comments to be reliable even if they're there.
Java's .jar files are often executable. For example, to run the ArgoUML software, here's the command line:
java –jar argouml.jar
Of course, there's some question as to which of the seven .jar files in the ArgoUML root directory you should run. In this case, you could figure that out just by looking at the README file. But if you haven't read the README, you could still take a good guess from the fact that argouml is the name of the project, so the others are probably related support libraries.
In this case, the other likely files are antlrall.jar, gef.jar, log4j.jar, nsuml.jar, ocl-argo.jar, and xerces.jar. Many of these names are recognizable as support projects. (antlr is a parser generator, gef is a graphics layout package, log4j is a logger, nsuml is a UML library, and xerces is an XML parser.) The ocl-argo.jar file might have been a good guess, but its manifest.mf file doesn't contain a Main-Class directive, so it's not executable.
Java programs also come in applets and servlets. For applets, there's often an .htm or .html test harness showing how to run it. This can be a pain, especially if it requires a particular version of Java built into your browser and you're running the wrong one. Servlets can be even more complicated, because they rely on deployment descriptors and the specifics of your application server. If they're not already installed—and I'm really not sure where to tell you where to go looking for them—you'll have to consult your application server's manual.
Sometimes there's no way to execute the code at all. The code you have might be just for a non-executable .jar, .DLL, or .so file; these are libraries that you can't actually execute until you've written a program to run them. Poke around for a samples, example, or test directory for a "test harness" (a sample program designed to show off or test the capabilities of the library). If no test harness is provided, you'll have to write one yourself, and that means reading code.