Download 212 Wrapup – Misc Topics

Command Line Compilation
Javadoc
Packages
Threads
Garbage Collection
Overview
There are no specifics from this lecture that I will ask you to remember or apply for the
exam. For example, you do not have to tell me how to create a package or how to edit
the path in Windows. I will, however, include several multiple-choice questions on the
topics we’re discussing today.
Today’s topics are not meant to be extensive. Rather, they are meant to give you a taste
of the kinds of things that will likely come up in the future for those of you taking
additional courses in programming. These notes are not intended to be complete. In
some cases, such as changing an environment variable in Windows, the notes will only
apply to specific versions of Windows (e.g. Windows 7 as opposed to Vista or XP). In
other words, this material is only to give you a theoretical introduction to some topics
you will likely encounter down the road.
Command Line Compilation
The command to compile a source code file (‘javac.exe’) is tucked inside a directory
somewhere inside your Java installation. On my computer, the path to the javac command
is: C:\Program Files (x86)\Java\jdk1.6.0_14\bin\javac.exe
Suppose I have a source code file: Human.java and I wish to compile it. I would need to go
to a command line prompt (e.g. C:\ prompt on a Windows machine), navigate to the folder
containing my source code file, then enter the command: javac Human.java
The problem is that on most machines, the operating system will have no idea what ‘javac’
is. As with fully-qualified package names in Java, operating systems also are unable to find
a file unless you either type the fully qualified name:
C:\Program Files (x86)\Java\jdk1.6.0_14\bin\javac.exe Human.java
or by including the operating-system equivalent of an import statement. In other words, we
need to figure out a way to tell the operating system where to look for ‘javac.exe’ whenever
it seems the command ‘javac’.
So far we haven’t had to worry about this since we’ve allowed our IDE (e.g. Textpad) to take
care of issuing the compile command for us.
However if we wish to issue the command ourselves from the command line, we first need
to give the operating system the path to the ‘javac.exe’ command.
Editing a Path in Windows XP
1. From the start menu, choose Control Panel, (click on Performance and Maintenance if XP),
then click on System. This brings up a window entitled "System Properties".
2. Click on the Advanced tab. Find the Environment variables button toward the bottom of the
window pane and click on it. This opens up a new screen entitled Environment Variables.
3. In the System Variables pane, scroll down to find PATH. Select it and click edit.
4. In the new window, check if the string that appears there already contains something like
this:
C:\Java\jdk1.6.0_14\bin; (Note that it may have a different version number – that’s fine as
long as there is a path there that only differs in the numbers that appear after jdk).
5. If it is already there, just click ok and get out. If this particular path is not there, then place
the cursor at the very end of the string that appears in the variable value field. The existing
string should end with a semicolon. If it does not, add a semicolon and then type
C:\Jjava\jdk1.6.0_14\bin;
6. Back to the System Variables pane, look for CLASSPATH. Select it and click edit.
7. In the new window, check if the string that appears there already contains this: .; (a period
followed by a semicolon). If it is there, click OK and you are done, if it is not there, place the
cursor at the very end of the string that appears in the variable value field. The existing
string should end with a semicolon. If it does not, add a semicolon. Then type a period (just
a single period with no other information). This means you should add the following to the
CLASSPATH: .;
8. After you've added the period to your CLASSPATH, save the changes and reboot your
machine. You do not need to reboot if you did not make any changes.
Packages / Import Statement
Packages are, among other things, a way of organizing classes. The Java API has hundreds and
hundreds of classes. There are extended versions of the Java API which add many more (e.g.
servlets). Then there are the infinite number of additional classes that programmers create on
their own. Because of the tremendous number of classes out there, It is easy to imagine that there
can be a conflict in which you have multiple classes with the same name.
For example, consider the class ‘Scanner’ is in the package java.util. When accessing the Scanner
class, we could write:
java.util.Scanner console = new java.util.Scanner();
This is known as a fully-qualified name. In other words, importing our packages is only about
proper identification and location of the class. By including the import statement, all we are doing
is giving ourselves a shortcut for identifying the Scanner class. Otherwise, we would have to type
the full ‘java.util.Scanner’ prefix every time we wnted to reference that class.
Also, suppose someone else had created a class which was also called Scanner. How could you refer
to both versions of the class given that they have the same name?
Answer: Use the fully-qualified name discussed above.
e.g. mypackage.util.Scanner s = new mypackage.util.Scanner();
We’ll discuss how to name packages shortly. We would also have to be sure that this package was
saved somewhere on our computer.
Packages and visibility: Packages have various Java properties such as being able to share data
whose visiblity is declared as ‘protected’.
Creating Your Own Packages
We typically create a package in order to group together a series of related classes. Creating
a package is not difficult. The trick lies in organizing where our packages are located on our
computers. The basic steps are as follows:
1. Choose a name. There is a convention to creating a package name: Take your e-mail
address such as [email protected] and put it backwards. You can append additional
information if and when you create multiple packages. So if I had a package called
‘medical’, I would call the package: edu.depaul.ymendels.medical. I could then
group all my medicine-related classes into this package.
2. Pick a root directory on your hard drive for all of your packages e.g. c:\javaclasses
3. From inside this root directory, create a folder tree using your package. Using our
‘medical’ example above, I’d create a folder called edu, a subfolder of that called
depaul, a subfolder called ymendels, and another subfolder called medical.
4. Save the .class files for all of your classes in the appropriate directory. In other words, all
the classes that make up your ‘medical’ package should be in the ‘medical’ folder.
5. Add the route directory of your package (e.g. c:\javaclasses) to the classpath
environment variable. I’ll discuss this further in lecture. There is no shortage of online
references discussing classpath online. It is also in the appendix of the Malik textbook.
6. For every class that you want to include in your package, include the statement:
package edu.depaul.ymendels.medical;
This statement must be the first line in the source code.
Note: The only statements (other than comments) in Java that do NOT appear in a class are
import and package statements.
JavaDoc
Java provides a lovely little tool for creating your own HTML-style APIs. This tools is called JavaDoc. To
create your own documentation, you must include one or more of the doc tags inside a slightly different
comment tag: /** to */ (note the extra star).
- By convention, each new line of a Javadoc typically includes its own asterisk.
Among many other situations, we typically include JavaDoc comments before all of your methods
describing what they do. We also have a comment describing each parameter of the methods, and
another for the return type if there is one.
If you know HTML, you can inclde markup if you like, although there are various limitations.
Some of the more commonly used doc tags are:
- @author
- @param
- @return
- @throws
Once you have written all of your JavaDoc, you can run the ‘javadoc’ command from a command line
(i.e. this is not a Java command) as follows:
javadoc Filename.java
and press enter. All kinds of HTML files will be generated. The file index.html is the one that you can
view in a browser to see the documentation for your class.
- Note that this command must be executed from the command line.
See the updated file MethodsPracticeWithJavaDoc.java for an example of a simple JavaDoc
Threads
On a computer with one processor, only one operation (e.g. adding two numbers) may be
executed at a time. Even if the entire computer was dedicated to your single Java program
(i.e. no other programs whatsoever running in memory), if your program is waiting for one
thing to take place (e.g. user input), then absolutely nothing else could take place until that
step was completed.
Threading gives the programmer the opportunity to essentially have mini-programs running
at the same time. Supposing your program is busy drawing various illustrations on the
screen, but at the same time, another part of your program was waiting for the user to
enter some information. A non-threaded program would sit there waiting patiently until the
user entered the input and would not continue its drawing. If, however, you put the
graphics drawing code in one thread, and the user-input code in a different thread, then you
could have the threads executing concurrently with each other.
On a single-processor computer, the processor would keep jumping back and forth between
the various threads to check to see what they needed done. The “waiting” thread (for user
input), would be given very little processor time until the user finally entered their
information. Meanwhile, the graphics-drawing thread would be allotted considerably more
processing time to do its thing.
So threads are a way of dividing your program into various individual pieces, each of which
is executed concurrently.
Garbage Collection
Objects take up space (memory). Consider:
Student s1 = new Student();
Student s2 = new Student();
s2 = s1;
In the above example, there are two areas of memory that have been reserved when we instantiated
our two Student objects. However, when we tell s2 to refer to the object s1, then the original object
being pointed to by s2 is still sitting out there taking up memory somewhere. And yet, there is NO
reference pointing to it. It is essentially lost in space (memory). In “older” languages such as C and C++,
this was wasted memory and was known as a ‘memory leak’. It was up to the programmer to explicitly
let the program know that the memory being de-referenced would no longer be needed. If the
programmer failed to do so, a memory leak would occur. In complicated programs with numerous
memory leaks, it would cause the program—and often the entire computer to operate more and more
slowly. In complicated software design, it was extremely common for memory leaks to occur.
With this problem in mind, the designers in Java introduced a feature called Garbage Collection.
Periodically, the JVM scans the program for objects in memory which have no references to them. Since
these objects are ‘lost in space’ and therefore effectively useless, the memory is released by the
program back and returned to the operating system.
Garbage collection has become such a popular feature, that other more recent languages such as
ObjectiveC have implemented similar functionality.