 |
 
 JAVA DEVELOPER'S RESOURCE |
|
JAVA DEVELOPER'S RESOURCE |
If you're reading the text version via Usenet, I do apologize that parts of it may be less intelligible than possible in HTML. Please refer to the HTML version at http://sunsite.unc.edu/javafaq/javafaq.html.
This document is Copyright 1995, 1996 by Elliotte Rusty Harold. For information about reproduction, redistribution and other such rights please see the end of this file.
for loops have the same syntax in all four languages);
but it is not based on any of those languages, nor have efforts
been made to make it compatible with them.Java is sometimes referred to as C++ ++ --. The language was originally created because C++ proved inadequate for certain tasks. Since the designers were not burdened with compatibility with existing languages, they were able to learn from the experience and mistakes of previous object-oriented languages. They added a few things C++ doesn't have like garbage collection and multithreading; and they threw away C++ features that had proven to be better in theory than in practice like multiple inheritance and operator overloading. (There's still argument over whether they made the right choices. I tend to think they were correct to throw out operator overloading and probably correct to throw out multiple inheritance. For now let's just say that neither choice is likely to be reviewed soon.)
Even more importantly Java was designed from the ground up to allow for secure execution of code across a network, even when the source of that code was untrusted and possibly malicious. This required the elimination of more features of C and C++. Most notably there are no pointers in Java. Java programs cannot (at least in theory) access arbitrary addresses in memory.
Furthermore Java was designed not only to be cross-platform in source form like C, but also in compiled binary form. Since this is frankly impossible across processor architectures, Java is compiled to an intermediate byte-code which is interpreted on the fly by the Java interpreter. Thus to port Java programs to a new platform all that is needed is a port of the interpreter.
Finally Java was designed to make it a lot easier to write bugfree code. Shipping C code has, on average, one bug per 55 lines of code. About half of these bugs are related to memory allocation and deallocation. Thus Java has a number of features to make bugs less common:
In 1989 Joy sold his Sun stock, invested heavily in Microsoft and moved out of mainstream Sun to Aspen, Colorado. By the early 90's Bill was getting tired of huge programs. He decided that he wanted to be able to write a 10,000 line program that made a difference. In late 1990 Bill wrote a paper called Further which outlined his pitch to Sun engineers that they should produce an object environment based on C++. Today Joy freely admits that C++ was too complicated and wasn't up to the job.
Around this time James Gosling (of emacs fame) had been working for several months on an SGML editor called "Imagination" using C++. The Oak language (now Java) grew out of Gosling's frustration with C++ on his "Imagination" project.
Patrick Naughton, then of Sun, now vice-president of technology at StarWave, started the Green Project on December 5th, 1990. Naughton defined the project as an effort to "do fewer things better". That December he recruited Gosling and Mike Sheridan to help start the project. Joy showed them his Further paper, and work began on graphics and user interface issues for several months in C.
In April of 1991 the Green Project (Naughton, Gosling and Sheridan) settled on smart consumer electronics as the delivery platform, and Gosling started working in earnest on Oak. Gosling wrote the original compiler in C; and Naughton, Gosling and Sheridan wrote the runtime-interpreter, also in C. (The Green project never wrote a single line of C++.) Oak was running its first programs in August of 1991. Joy got his first demos of the system that winter, when Gosling and Naugton went skiing at Joy's place in Aspen.
By the fall of 1992 "*7", a cross between a PDA and a remote control, was ready In October of 1992 this was demoed to Scott McNealy, Sun's president, who was blown away. Following that the Green Project was set up as First Person Inc., a wholly owned Sun subsidiary.
In early 1993 the Green team heard about a Time-Warner request for proposal for a settop box operating system. First Person quickly shifted focus from smart consumer electronics (which was proving to be more hype than reality) to the set-top box OS market, and placed a bid with Time-Warner.
Fortuitously, Sun lost the bid. The Time-Warner project went nowhere, the same place it probably would have gone if Sun had won the bid. First Person continued work on settop boxes until early 1994, when it concluded that like smart consumer electronics settop boxes were more hype than reality.
Without a market to be seen First Person was rolled back into Sun in 1994. However around this time it was realized that the requirements for smart consumer electronics and settop box software (small, platform independent secure reliable code) were the same requirements for the nascent web.
For a third time the project was redirected, this time at the web. A prototype browser called WebRunner was written by Patrick Naughton in one weekend of inspired hacking. After additional work by Naughton and Jonathan Payne this browser became HotJava. The rest, as they say, is history.
Information in this section is primarily based on the first hand accounts of Bill Joy and Patrick Naughton (which don't always agree). No doubt other people have still different memories of what occurred. If you've got any more first hand information about what went on in the Green project I'd like to hear from you.
At the lowest level the advantage of Java to the web is that it provides a secure, cross-platform way for code to be executed. At a somewhat higher level Java adds several features to existing web sites:
An IRIX port
has mostly been completed by
A Linux port has been mostly completed. See http://java.blackdown.org/java-linux.html.
IBM has ported Java to OS/2 and AIX. See http://ncc.hursley.ibm.com/javainfo/ . IBM is also rumored to be porting Java to Windows 3.1. However for various reasons such a port is extremely difficult.
The OSF is porting Java to Unixware, HP/UX, Sony NEWS and Digital Unix. The alpha 3 HP/UX (9.0 and 10.0) and Unixware 2.0 ports are available. See http://www.osf.org/mall/web/javaport.htm.
Other ports are underway for Nextstep, SunOS 4.1, the Amiga and possibly other platforms.
In the past new versions of Java have most often been made available first for Solaris. If you have to have the latest version as soon as it's released, or if you're developing "Bet your company" applications with Java, you should probably be running Solaris on a SparcStation. Otherwise, if you just want to learn the language, you can get away with an Intel based Windows 95 or NT machine with a lot of RAM.
Netscape 2.0 and later will play Java applets on Windows NT, Windows 95, Solaris, SunOS 4.1, Linux and most other Unix platforms. A beta version of Netscape 2.0 for the Mac also supports Java.
A little further out in left field, it isn't even necessary to know Java to write Java programs. Intermetrics is beta testiing an ADA-95 to Java byte code compiler. Other such cross-compilers are probably possible including ANSI Fortran-77. However the one most people probably want, that is a C/C++ to Java byte code compiler, is probably not possible due to the severe limitations Java places on pointers.
This site has grown quite busy and is mirrored in several other places including
When you send email to these lists never, never cross-post. If you can't decide where your message properly belongs flip a coin. Please don't send it to every single list.
There is also a mailing list about Java, Kerberos and DCE at java-kerberos@lists.stanford.edu. To subscribe send email to majordomo@lists.stanford.edu with the words "subscribe java-kerberos" in the BODY of your mail message.
The Java Handbook
by
For details about these and many more books see http://sunsite.unc.edu/javafaq/books.html
int) Java specifies
everything.
Here are the detailed data types:
boolean
true and false only.
true and false are defined constants of the language and are not the same as True and False, TRUE and FALSE, zero and nonzero, 1 and 0 or any other numeric value. Booleans may not be cast into any other type of variable nor may any other variable be cast into a boolean.
byte
short
int
long
float
Like all numeric types floats may be cast into other numeric types (byte,
short, long, int, double).
When lossy casts to integer types are done (e.g. float to short) the fractional part is truncated and the
conversion is done modulo the length of the smaller type.
double
char
Chars are not the same as bytes, ints, shorts or Strings.
sizeof isn't necessary in Java because all sizes are precisely
defined. i.e. an int is always 4 bytes.
This may not seem to be adequate when dealing with objects that
aren't base data types. However even if you did know the size of
a particular object, you couldn't do anything with it anyway.
You cannot convert an arbitrary object into bytes
and back again.
if, else, for, while, do while and switch statements.
The syntax is identical to C's. However all condition tests must return boolean values. Since assignment and arithmetic statements
do not return a boolean value,
some of the more obfuscated condition tests in C are prohibited.
argv has become a string array
commonly called args and args[0] is the first command line argument,
not the name of the program. The other arguments are all shifted one to the left from
where they'd be in C or C++.
/* This is a comment */ comment from C and the // This is a C++ comment
However comments that begin with a /**
are treated specially by the compiler.
These comments should only
be used before a declaration.
They indicate that the comment should be included in automatically
generated documentation for that declaration.
Superclasses of a class are indicated with the extends keyword rather than with
a :.
Features removed that make Java easier to read and understand than C++
include #define, typedef, operator overloading, enum, unions
and structs.
The main feature removed to make Java safer and more robust than C++ is pointer arithmetic.
Other features removed include global variables, standalone functions (everything is a method), friend functions (Everything in a package is a friend of everything else in the package.) and non-virtual functions.
A number of features have been added to Java to make it safer including true arrays with bounds checking, garbage collection, concurrency, interfaces (from Objective C) and packages. There is no need to explicitly allocate or free memory in Java.
Long answer: Object variables in Java are all references. A reference would be a pointer in any other language. The main difference is that you can't do pointer arithmetic on references. Therefore wherever you'd use a pointer to an object in C++, in Java you should just use the object itself.
On the other hand the primitive data types (int, float,
double, char, byte, short, long and boolean) are not
references. If you want to get a reference to one of these
you need to wrap it in a class first. Java provides
ready-made type-wrapper classes in the java.lang package
for Boolean, Character, Integer, Double, Float,
and Long. Bytes and shorts can be stored in the Integer class as well.
import java.io.*;
class ReadRawData {
public static void main (String args[]) {
boolean done = false;
byte b[] = new byte[1024];
int num_bytes = 0;
FileInputStream fin = null;
try {
fin = new FileInputStream(args[0]);
}
catch(ArrayIndexOutOfBoundsException e) {
System.out.println("You have to give me the name of a file to open.");
System.exit(0);
}
catch (FileNotFoundException e) {
System.out.println("Could not open input file " + args[0]);
System.exit(0);
}
catch(IOException e) {
System.out.println("Error while opening input file" + args[0]);
System.exit(0);
}
catch (Exception e) {
System.out.println("Unexpected exception: " + e);
System.exit(0);
}
try {
num_bytes = fin.read(b);
}
catch(IOException e) {
System.out.println("Finished Reading: " + e);
done = true;
}
catch (Exception e) {
System.out.println("Unexpected exception: " + e);
System.exit(0);
}
while(!done) {
System.out.write(b, 0, num_bytes);
try {
num_bytes = fin.read(b);
}
catch(IOException e) {
System.out.println("Finished Reading: " + e);
done = true;
}
catch (Exception e) {
System.out.println("Unexpected exception: " + e);
System.exit(0);
}
if (num_bytes == -1) done = true;
} // end while
} // end main
} // end ReadRawData
// Implement the Unix cat utility in java
import java.io.*;
class cat {
public static void main (String args[]) {
String thisLine;
//Loop across the arguments
for (int i=0; i < args.length; i++) {
//Open the file for reading
try {
FileInputStream fin = new FileInputStream(args[i]);
// now turn the FileInputStream into a TextFileStream
try {
DataInputStream myInput = new DataInputStream(fin);
try {
while ((thisLine = myInput.readLine()) != null) { // while loop begins here
System.out.println(thisLine);
} // while loop ends here
}
catch (Exception e) {
System.out.println("Error: " + e);
}
} // end try
catch (Exception e) {
System.out.println("Error: " + e);
}
} // end try
catch (Exception e) {
System.out.println("failed to open file " + args[i]);
System.out.println("Error: " + e);
}
} // for ends here
} // main ends here
}See the Java class API documents for details of the syntax for these methods.
DataInputStream.readline()
as discussed in the previous question.Next use the StringTokenizer class in java.util to split the String into tokens. By default StringTokenizer splits on white space (spaces,tabs, carriage returns and newlines) but that is user definable.
import java.util.StringTokenizer;
class STTest {
public static void main(String args[]) {
String s = "9 23 45.4 56.7";
StringTokenizer st = new StringTokenizer(s);
while (st.hasMoreTokens()) {
System.out.println(st.nextToken());
}
}
}
9 23 45.4 56.7Finally you convert these tokens into numbers using the type wrapper classes as described in the next question.
class ConvertTest {
public static void main (String args[]) {
String str;
str = "25";
int i = Integer.valueOf(str).intValue();
System.out.println(i);
long l = Long.valueOf(str).longValue();
System.out.println(l);
str = "25.6";
float f = Float.valueOf(str).floatValue();
System.out.println(f);
double d = Double.valueOf(str).doubleValue();
System.out.println(d);
}
}
Within an application, however, file access is straight-forward. There are several ways but here is a simple example using formatted output streams:
import java.io.*;
class PrintToAFile {
public static void main (String args[]) {
//First open the file you want to write into
try {
FileOutputStream fout = new FileOutputStream("test.out");
// now convert the FileOutputStream into a PrintStream
PrintStream myOutput = new PrintStream(fout);
// Now you're able to use println statements just as if you were using System.out.println
// to write to the terminal
myOutput.println("Hello There!");
myOutput.println(1 + " + " + 1 + " = " + (1+1));
}
catch (IOException e) {
System.out.println("Error opening file: " + e);
System.exit(1);
}
} // main ends here
}
You should also learn about DataOutputStreams and the
write() method when you get a chance.
DataOutputStreams and DataInputStreams are used for moving
data between Java programs in a portable way. The various
incarnations of the write() method are used for writing and
reading arbitrary byte streams. What we've demonstrated here
is more suitable for human consumption.
Several people have written to me with apparently different methods that involve deep, dark hacks to the java interpreter, dump and undump and other tricks. However so far I don't understand any of this.
An abstract class cannot be instantiated. Only its subclasses can be instantiated.
In the future a serialization interface will be added to the language. It is currentyl in alpha.
For applets on the same page Arthur van Hoff has provided this example:
Applet 1:
import java.awt.*;
public class Applet1 extends java.applet.Applet {
public boolean handleEvent(Event evt) {
Applet2 buddy = (Applet2)getAppletContext().getApplet("buddy");
return (buddy != null) ? buddy.handleEvent(evt) : false;
}
}
import java.awt.*;
public class Applet2 extends java.applet.Applet {
String str = "";
public boolean handleEvent(Event evt) {
str = evt.toString();
repaint();
return true;
}
public void paint(Graphics g) {
g.drawString(str, 0, size().height * 2 / 3);
}
}
<HTML>
<HEAD>
</HEAD>
<BODY>
<applet code=Applet1.class width=100 height=100></applet>
<applet code=Applet2.class width=400 height=30 name=buddy></applet>
</BODY>
</HTML>
To prevent this, you need to create an Image member of your applet.
Then override the update() method
with one that draws to this
(offscreen) Image. Finally, in your paint() method, do nothing but use
Graphics.drawImage() to copy this offscreen bitmap onto the screen. All other
drawing takes place offscreen in the update() method.
Extensions are planned for the class library though. In particular Sun is working on extensions for 3D, multimedia, telephony, improved graphics and multicasting.
int or float to an
Object such as an Integer or a Float.
However the proper way to do this isn't very
hard. Instead do
int x = 5;
myInteger = new Integer(x);
print().
Note that some of the classes like DataOutputStream have unoverloaded
methods like writeInt() and writeByte().
Methods and variables may be declared final as well. This means they may not be overridden in a subclass.
It's also possible to make a static variable final to get the effect of C++'s const statement or some uses of C's #define, e.g.
public static final int myVar = 0
Static methods can be referenced with the name of the class rather than the name of a
particular object of the class (though that works too). That's how library
methods like System.out.println() work.
PERFORM or BECOME
in Java. These
would probably open security holes. There are workarounds for some things you might want to do
using interfaces.
Instead if you need to do clipping, create separate offscreen Images for each clipping region. Each Image should be the size of the clipping region you desire. Draw into those offScreen Images, and then copy them onto the appropriate section of the of your applet window using java.awt.Graphics.drawImage(). Some coordinate conversion will almost certainly be necessary.
If the background image isn't a simple color then you'll first need to copy the appropriate part of that image to your offscreen clipping Image. You can do this by drawing your background Image into your offscreen region with Graphics.drawImage and a suitable shifting of coordinates.
This all works for rectangular regions only since all Images are rectangular. More complicated geometries can be faked if all but one section contains only simple colors.
Unlike most random functions in other libraries the Math.random() method seeds itself
with the current time in milliseconds. Thus you do not need to seed it explicitly at the start of your program. If you require a non-random Random() for test purposes or you need more randomness than the current time in milliseconds can provide, then you can use java.util.Random() which has a constructor that lets you specify a seed.
The cookbook approach is simple. Add the following three private member variables to your applet and the public update method. Flicker will magically disappear.
private Image offScreenImage;
private Dimension offScreenSize;
private Graphics offScreenGraphics;
public final synchronized void update (Graphics g) {
Dimension d = size();
if((offScreenImage == null) || (d.width != offScreenSize.width) || (d.height != offScreenSize.height)) {
offScreenImage = createImage(d.width, d.height);
offScreenSize = d;
offScreenGraphics = offScreenImage.getGraphics();
}
paint(offScreenGraphics);
g.drawImage(offScreenImage, 0, 0, null);
}
The CLASSPATH is an environment variable that defines where Java looks for these imported classes. If the CLASSPATH isn't set properly every program written in Java won't be able to run.
Thus when you import java.applet.Applet java tries to find the relevant code in $CLASSPATH/java/applet/Applet
If there are multiple directories in $CLASSPATH then each of them will be searched in order from left to right. In Netscape you should make sure that the first directory in CLASSPATH. is the directory that contains netscape's class files (The defaults are /usr/local/netscape/java/classes on Unix and C:\NETSCAPE\NAVIGATOR\Program\java\classes in Windows.)
setenv CLASSPATH my_class_directoryUnder Windows this is set by adding the line
SET CLASSPATH=C:\JDK\JAVA\CLASSES;to your autoexec.bat file. You can of course point it at a different directory, but then your classes should reside in that directory.
If the class is part of a package then it needs to be in the appropriate subpath of the CLASSPATH directory. For instance if your class is part of package foo.bar, then it should be in $CLASSPATH/foo/bar.
System.out.println(Double(0.56).toString());
You must use the new operator like:
Double myDouble = new Double(0.56);
System.out.println(myDouble.toString());
System.out.println((new Double(0.56)).toString());new operator.
In Netscape the user doesn't even get the keys to the cage so you can't let the applets out into your system even if you wanted to. With the Applet Viewer it is possible to give your applets more access to the system. However they still can't do everything a C program can do.
Specifically a Java applet cannot write anything to a hard drive without permission. It cannot write directly to memory, and it cannot introduce a virus into your system. A Java applet can use a lot of your CPU time though not 100% of it. It cannot crash your system (though a Java enabled browser can).
Finally an applet can display pictures or text or play sounds which the user may find annoying or offensive, but this hardly qualifies as a security flaw and is not unique to Java enabled browsers.
Natural Intelligence's Roaster is a PowerMac hosted applet development environment. It has been designed from the public specs with no help from Sun. It is still alpha quality. I do not recommend it.
Metrowerks added Java support to Code Warrior 9 for the Mac in May, 1996. Metrowerks has licensed Sun's source code. The Java support is alpha quality, and is not by itself worth the price of Code Warrior, even the $99 Java only edition. However if you also need a C compiler it doesn't cost you anymore to get Java support.
Sun has announced a payware IDE currently referred to as "Solstice Workshop". It is currently in public beta test, but is probably not worth the download time yet. Solstice Workshop is similar to Sun's existing Workshop products for Fortran and C++. However it is written entirely in Java.
Aleda Freeman has created an excellent page on Java IDE's and other tools at http://www.cybercom.net/~frog/javaide.html. This site has descriptions of and links to IDE's, database connectivity tools, and more.
The Java source code is freely available for non-commercial use though a license must be signed. If you want to license the Java source code for commercial use you will need to pay $125,000 for the first platform, $25,000 per additional platform and a $2/unit royalty. Annual upgrades are $50,000 plus $5,000 for each additional platform. Complete details are at http://www.javasoft.com/java.sun.com/source.html.
Furthermore whether your product is commercial or non-commercial you may not use the trademark "Java" to describe your product unless you pass an as yet unreleased verification and test suite.
Why am I taking on such a Herculean task? It's often said that you never really understand a subject until you teach it. I'm going to endeavor to learn Java and understand it by teaching it. The result should be interesting at least. Since I'm very new to Java and clearly do not yet understand the language, I'll have a perspective on the issues that should be helpful to newcomers.
Are there mistakes here? Absolutely. I hope people here and elsewhere will correct me gently and help lead me on the path to true Java enlightenment when I err. And if they aren't so gentle, well, I've developed a pretty thick skin after five years of Usenet.
My companion tutorial in how to write Java is going to reflect the programs I'm actually writing. As I learn to do a Hello World program, I'll write about Hello World. (OK, I've actually already gotten beyond Hello World but not much beyond.) How fast the FAQ list grows will depend in large part on how fast my skills grow. You'll get to watch me learn, make mistakes, correct mistakes and so on.
There may be an advantage to this approach. People who want to learn Java will be coming from almost identical places as me. I always hate having to write down or talk down to people, and I don't do it very well. Similarly I find it frustrating to try to communicate with people who are way beyond me (as obviously some people on the Java mailing lists are). Right now I am at the level of the lowest of the low. This means that I can write for people without much prior experience without boring myself or, hopefully, my audience, to tears.
Finally I'll emphasize that I'm not trying to prevent anyone else or any other team of people from taking on a similar project. I hope someone does. I'll probably learn from what they do, and they'll learn from what I do, even if it's only to learn the sorts of things novices are confused about. And of course not everyone shares the same learning style so while some people may enjoy my approach to Java I am sure others will find it dense, incoherent and ultimately incomprehensible. More choices are better.
Ultimately I'm doing this because I think Java is very, very cool and I am convinced I need to learn it sooner rather than later. I think this project will propel my Java knowledge forward, and if it does that I'll consider my project a success. If I can help a few other lost souls to climb out of the pit with me at the same time, so much the better.
However I do not allow the FAQ list, either the text or HTML version, to be placed on any web sites but my own. Mirroring HTML files is a fundamentally bad idea that is at cross-purposes with the design of the web. Among other problems it makes maintaining up-to-date copies phenomenally difficult. If you think this file would be a useful addition to your web site, then link to it. That's the way the web is designed. Not all information needs to reside in one central location. No permission is needed to link to this or any other of my HTML files. In fact I'd prefer it if you'd not ask me, since then I don't have to spend time answering you.
Although there's more reason to want to translate the document rather than merely mirror it, I regret that I do not have the time or resources to support any translation efforts. This document will be available in English only for the foreseeable future.
If you want to use the source code samples included here, please do. I consider the source code (though not the FAQ list itself!) to be public domain with the exception of the two samples from Arthur Van Hoff. (You'll have to ask him about them.) No permission is necssary to reuse, edit, modify or publish any of my source code contained in this FAQ list.
Copyright 1996 Elliotte Rusty Harold elharo@sunsite.unc.edu
 | © Prentice-Hall, Inc. A Simon & Schuster Company Upper Saddle River, New Jersey 07458 |