For more information, including links for purchasing these books online, please see the editions page.
In older editions, the publisher used a thicker paper. It was cheaper and gave the book added "shelf presence". As the page count increased, the publisher had to switch to thinner paper. Starting with the 6th edition, the design has changed a bit to conserve paper. The thinner books actually have more information.
Unfortunately no. There are numerous revisions in all chapters, so it isn't just a matter of giving out the new chapters for free. We looked at offering a rebate if you turn in your old copy to the bookstore, but the bookstores balked at that.
It really doesn't matter, does it? Java is cross-platform. At any rate, after some readers complained on Amazon.com that the book is “Windows-centric”, I took all screen shots on Linux and changed all backslashes in path names to forward slashes. Those were the only “Windows-centric” aspects of the book, but apparently they were enough to offend the purists.
Under Windows, select the MS-DOS Prompt or Command Prompt application from the start menu. There are many tutorials on the net—you may want to search Google to find one that you like.
On Mac OS X, run the Terminal application. (Sorry, I don't know how to do this in Mac OS 9—you may need to purchase a Java development environment, such as Metrowerks.)
javac under Windows 9x/ME, and my program has so many errors that they all flash by and I can only see the last few. I even tried redirection (javac MyProg.java | more or javac MyProg.java 2> errors.txt ), and it doesn't work.
The javac compiler sends error messages to the standard error stream, not the standard output stream. Unfortunately, the Windows 9x/ME shell does not allow redirection of the standard error stream to a file.
Remedy: Use the errout.exe program to redirect the standard error stream to the standard output stream:
errout javac MyProg.java | more errout javac MyProg.java > errors.txt
This is a simple C program—source code below:
#include <io.h>
#include <stdio.h>
#include <process.h>
int main(int argc, char* argv[])
{
dup2(1, 2); // make stderr go to stdout
execvp(argv[1], argv + 1);
return 0;
}
Or, if you prefer a pure Java solution, compile the following Java class:
import java.io.*;
public class Errout
{
public static void main(String[] args) throws IOException
{
Process p = Runtime.getRuntime().exec(args);
BufferedReader err
= new BufferedReader(new InputStreamReader(p.getErrorStream()));
String line;
while ((line = err.readLine()) != null)
System.out.println(line);
}
}
Then execute the following command:
java Errout javac MyProg.java | more java Errout javac MyProg.java > errors.txt
It is the path and/or class path.
Do the following. First, deactivate any Java installation that you may have. That is, temporarily remove Café, the JDK you downloaded yesterday, the beta test of the nifty new environment that your brother in law gave you, etc. Install the SDK from the Sun web site. Download the Core Java files from the Prentice-Hall web site. Set the path and remove any class path settings. Reboot. Double-check that the class path is either unset or contains the current directory (.). Keep trying. This stuff always works out eventually.
Sun put out detailed installation instructions and an excellent tutorial that walks Windows users through all the steps in excruciating detail.
I have had to deal with dozens of users who swore that they did everything right, except they sheepishly admitted a couple of emails later that they didn't pay attention to capitalization, thought that there was no essential difference between a ; and a :, thought it was ok to add a few spaces to "improve" on the looks of the class path, didn't want to go through the trouble of deactivating their old version of Java, or whatever. Please: If the Java interpreter can't find some or all of the classes, check your path and class path, and don't report it as an error. Thanks!
In Java 2, this can happen if you have a class path but you forget to add the current directory (.) into it. This is because system classes (the ones in rt.jar) are always part of the class path. The current directory is also automatically searched if no explicit class path is provided. However, if an explicit class path is provided, the current directory is automatically searched by javac but not by java.
Please contact the vendor, Helios Software.
You need to install the Java Plug-in to run Java 2 applets in Netscape 4 or Internet Explorer. Netscape 6 and above, Mozilla, and Opera, have versions that include the Java Plug-in.
SQL Exception: SQL State:08001 Message:No Suitable Driver Vendor:0
You need to install a database and a JDBC driver and then edit the MakeDB.properties file to reference your driver. You also may need to change the class path to include the location of your driver. For instructions, please refer to the documentation from your database vendor.
The RMI setup is complex and it is very easy to get some detail wrong. Also, remember to always erase unneeded class files and to restart the naming service whenever you make a change in the configuration. Keep trying—it'll work eventually.
Install the Java SDK and use the jar program: jar xvf corejava.zip.
Format class in a commercial product, but the license for the book code only grants the rights for noncommercial use.
The Format class (JAR, 20 kb) is now available under LGPL.
The warning is: "Method boolean isActive() in class AppletFrame does not override the corresponding method in class java.awt.Window. If you are trying to override this method, you cannot do so because it is private to a different package."
Oddly enough, there is a package visible method isActive in the Window class that I neither knew nor cared about—I must override the public isActive method in the AppletStub interface. The warning says that if I am trying to override the former, I will not succeed. That is fine with me. What is interesting is that the AppletFrame class now has two methods with identical name and signature, but different visibility. If its isActive method is ever called by any method defined by a class in the java.awt package, then that refers to the original Window.isActive method. However, if it is called by any other method, then it refers to the AppletFrame.isActive method.
This shows an interesting usage for package visibility. Had isActive been a public method, then I would not have been able to meaningfully extend from Frame and implement AppletStub —there would not have been one appropriate implementation of isActive for both. By giving isActive package visibility, it can be called by other classes in the java.awt package (it is actually called twice, by Container.proxyRequestFocus and Component.ensureWindowActivation ), and I can still construct subclasses that mix in interfaces with the same method name.
Read Prentice Hall PTR to stay on the cutting edge of computer science and engineering.