 |
CS 696 Emerging Technologies: Distributed Objects |
|
|---|
Spring Semester, 1998
Java on Rohan - Corrected
To Lecture Notes Index
© 1998, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 21-Apr-98
Contents of Doc 2, Java on Rohan - Corrected
- References
- Some Java Information
- Java on Rohan
- Classpath
- SDSU Java Library
- Packages
- Javadoc
Javadoc documentation at:
http://www.ssu.edu/doc/jdk1.1/docs/tooldocs/solaris/javadoc.html
FixJavadoc documentation at:
http://www.elisdsu.edu/java-SDSU/sdsu.doc.FixJavadoc.html
Rohan system administrator
The Java Programming Language, Arnold, Gosling, 1996
Version of Java available:
JDK 1.0.2
- Compatible with Netscape 3.0 browsers
- For applets
JDK 1.1.3
- Last semester this was the only version of java that would run an
application that used a GUI (awt) and display it on the NCD terminals in the
campus labs
JDK 1.1.5
- Current release of Java
JDK 1.2b2
- Second beta version of the next major release of Java
-
- API is at least twice the size of the 1.1.x API
Default Version
/opt/java points to the current "safe" version of java on rohan
Java GUI Applications & NCD Terminals
There is problem running a java GUI based application on the NCD terminals on
campus
The problem is with the old version of the NCD software (3.x) running on the
NCD terminals
Reports are that version 5 of the NCD software fixes the problem, however NCD
does not support the version of the terminals in BAM and in E301. A few
terminal in the library can run version 5
This does not affect applets running in a browser, but does affect applets
running in the appletviewer
You must type
xstdcmap -all"
at the shell prompt before you run a java application that uses AWT and have it
display on an NCD X-terminal in the BAM labs
This does not work with some window managers like fvwm
In JDK 1.1.5 and 1.2b2 the window coordinate system on the NCD is off by 10-30
pixels
- You need add 10-30 pixels to the y coordinate system so that the top of the
window is accessible
Using a Version of Java
Add to your path the location of the java bin directory of the version you wish
to use
| JDK | location |
| 1.0.2 | /opt/java1.0.2/bin |
| 1.1.3 | /opt/jdk1.1.3/bin |
| 1.1.5 | /opt/jdk1.1.5/bin |
| 1.2b2 | /opt/jdk1.2beta2/bin |
| Current version | /opt/java/bin |
Warning!
As new versions of Java are released older versions of the JDK will be removed
from Rohan
If you hard code in your path a particular jdk, when it is removed, you will
have to modify your path
/opt/java was created to allow users to avoid having to change their
environments each time a new version of jdk is released
You can use a version of java not on your path by explicitly referencing it in
the command line:
/opt/jdk1.2beta2/bin/javac foo.java
/opt/jdk1.2beta2/bin/java foo
If you do this a lot alias the command
Set the CLASSPATH environment variable to point to locations that contain java
packages that you with to use
There is no need to include the location of the standard Java packages, it is
done for you by java
The following classpath will access classes in the current directory, the SDSU
Java library, and all the Java API of the version of java you are running
setenv CLASSPATH '.:/usr/local/lib/java'
I use the following classpath to access Java classes in my home directory
setenv CLASSPATH '.:/usr/local/lib/java:/home/ma/whitney/java/classes'
Currently there are some problems using the classes.zip file in
/usr/local/lib/java, so it is better to use the classpath given above
Note /opt/local and /usr/local are refer to the same directory on Rohan
The SDSU Java library contains ~100 classes, some of which may be useful in
your assignments
The library is on Rohan, Moria and is free
Documentation is at:
http://www.eli.sdsu.edu/java-SDSU/em>
You can also download the library from that URL
Each class belongs to a "package"
A package creates a name space
A package defines the full name of a class
Standard packages
| java.applet | java.awt.peer | java.net |
| java.awt | java.io | java.util |
| java.awt.image | java.lang | sun.tools.debug |
Example - PrintStream
PrintStream is in the java.io package
The full name of the class is java.io.PrintStream
class Output {
public static void main( String args[] ) {
java.io.PrintStream myOut = System.out;
myOut.print( "Look Mom, No System.out" );
}
}
Import Statement
The import statement allows you to shorten class names
import java.io.PrintStream;
class Output {
public static void main( String args[] ) {
PrintStream myOut = System.out;
myOut.print( "Look Mom, No System" );
}
}
import java.io.*;
class Output {
public static void main( String args[] ) {
PrintStream myOut = System.out;
myOut.print( "Look Mom, No System" );
}
}
Default Import
All classes in the java.lang are imported in all programs by default
Placing a class in a package
package sdsu.roger;
public class Sample {
public void hello() {
System.out.println( "Hello for package sdsu.roger" );
}
}
Place
program in file named "Sample.java"
Place file "Sample.java" in directory called "roger"
Place directory "roger" in directory called "sdsu"
Place directory "sdsu" in "~whitney/java/classes"
- Placing classes in a directory called classes is just a convention that I
use, it is not required
Make sure that "~whitney/java/classes" in the CLASSPATH environment variable
- setenv CLASSPATH
-
- '.:/opt/java/classes:/home/ma/whitney/java/classes'
Place the following class anywhere you like and compile
import sdsu.roger.Sample;
class TestPackage {
public static void main( String args[] ) {
Sample me = new Sample();
me.hello();
}
}
Class Access Levels
Public
- Accessible to code in and outside a package
Package
- Accessible to code in package only
- No subclasses outside package
package Botany;
public class Leaf
{
public Leaf()
{
System.out.println( "Leaf in a real tree" );
}
}
package Botany;
class BotanyHelper
{
// Only code in package Botany can use this class
}
Package Notes
If a class has no declared package, it is in the unnamed package
CLASSPATH needs to point to the root directory containing the binaries of
packages
There is no requirement to have both binaries and source code of a package in
the same location.
Using Javadoc
There are three steps in creating java documentation using javadoc. First there
is inserting the proper comments in your source code. Second is running
javadoc. Third is modifying the output of javadoc to properly find the standard
images use in javadoc documentation.
Javadoc Comments
Comments that start with /** and end with */ that are placed just before
methods, constructors, fields, classes, and interfaces are used by javadoc to
generate javadoc documentation. The following small example illustrates some
javadoc comments. See
http://www.sdsu.edu/doc/jdk1.1/docs/tooldocs/solaris/javadoc.html for more
details on javadoc comments and the javadoc tags.
Sample Program with Javadoc tags
package cs535;
import java.io.IOException;
/**
* This is a javadoc comment for the entire class. Below I
* use some special tags.
*
* @version 0.1 28 November 1997
* @author Roger Whitney
* (<a href=mailto:whitney@cs.sdsu.edu>whitney@cs.sdsu.edu</a>)
* @see java.io.Writer
* @see java.util.Vector
*/
public class SampleClass
{
/**
* This is a javadoc comment for a field.
*/
private int myField;
/**
This is a javadoc comment for a method. Note that
I don't need to use the line of *'s at the left.
@param right Describe right here.
@param left Describe left here.
@exception IOException Talk about the exception here.
@return a float value is returned
*/
public float test( int left, int right ) throws IOException
{
return 5.0f;
}
}
Running Javadoc
See http://www.ssu.edu/doc/jdk1.1/docs/tooldocs/solaris/javadoc.html
for the "official" documentation on javadoc with all the flag options. The most
common mistake beginners make it javadoc is not making their classes public.
Javadoc does not produce documentation for non-public classes. Another common
mistake is not using the proper flags to display all the javadoc tags in your
classes. Not all tags are displayed by default. The general format of the
javadoc command line is:
javadoc [options] packages or files to process
For example I put the above program in a file SampleClass.java in the directory
/net/www/www eli/java/cs535. I then moved to the directory /net/www/www
eli/java. I then ran the following command:
javadoc -version -author -d myDocs cs535
The -version -author flags tell javadoc to show the version and author tags.
The -d myDocs flag tells javadoc to place the html documentation in the
directory myDocs. This directory must exist before you run the command. The
path cs535 tells javadoc to process all .java files in the subdirectory cs535.
You can give relative or absolute path name. You can also give a path to the
top level of a package to have javadoc generate documentation for all classes
in a package. The contents of myDocs is now:
AllNames.html cs535.SampleClass.html tree.html
Package-cs535.html packages.html
The following command done in the directory /net/www/www-eli/java/cs535 (which
contains the file SampleClass.java) will generate the javadoc documentation for
all files ending in .java in the current directory.
javadoc *.java
Modifying Javadoc output
Javadoc has one irritating feature: it assumes that all images used in the
javadoc html documentation are in a subdirectory of the directory containing
the javadoc documentation. When you view this documentation with a web browser
you will see boxes there the images for methods, constructors, fields, etc.,
should be located. There are two ways to correct this. The first one is to copy
the directory of images to the directory containing your javadoc documentation.
The second way is modify the html files to reference a local where the images
are actually located.
FixJavadoc
The Java class sdsu.doc.FixJavadoc modifies .html files so that the images are
referenced from a valid location over the network. To modify all .html files in
the current directory use the command:
java sdsu.doc.FixJavadoc
See http://www.elisdsu.edu/java-SDSU/sdsu.doc.FixJavadoc.html
for more details and options.
visitors since 03-Feb-98