The table below gives the assignments, and associated dates. All future dates are tentative until such assignments are made available.
Program | Topic | Date |
---|---|---|
prog01 | WebHistory | 8pm Monday, 9 September 2002 |
prog02 | Merging (Singly) Linked Lists | 8pm Monday, 16 September 2002 |
prog03 | Memory Management (Linked Vectors) |
8pm Monday, 23 September 2002 |
prog04 | Maintaining a List of Cards | 8pm Monday, 7 October 2002 |
prog05 | Arithmetic Expression Trees | 8pm Monday, 21 October 2002 |
prog06 | Bin Packing | 8pm Monday, 11 November 2002 |
prog07 | Radix-sort vs. Quick-sort | 8pm Monday, 25 November 2002 |
prog08 | (2,4) Trees | 8pm Wednesday, 4 December 2002 |
GENERAL INFORMATION ABOUT PROGRAMMING
For many assignments, we will have provided you with a number of files containing source code which need not be modified. In such cases, there is no need for you to re-submit these files - we have them already.
The content of the file should generally include
In such cases, please make sure that your input files conform strictly to the expected format standards when the program driver is run using your file as input. Again, such input files must be submitted as a plain unformatted text file (for instance one created with "Notepad" on a Windows system). Do not submit any formatted files such as those produced by Microsoft Word or other word processors.
Manyintegrated development environments (IDEs) have been created which sit on top of JDK, providing graphical interfaces and more functionality (though usually at the expense of slower running times and the possibility of additional bugs in their software). The software in our department labs currently includes Symantec's Visual Cafe 4.1, the BlueJ 1.1.3 interactive Java Environment from www.bluej.org, Borland's JBuilder 5.0 and Sun's Forte 3.0 IDE. So long as you submit the pure source code files with the .java suffix, you may feel free to use any such development environment with which you are comfortable.
Our goal for this course will be to minimize all issues involving I/O as much as reasonably possible. We will not sponsor any specific I/O package in this class. In fact, for the most part when our programs rely on text files as input, we will use a very "simple" file format, and generally we will provide you with drivers so that you do not have to write much code involving fetching input.
Any code which we provide will use only routines which are standard in Java, so you should be able to use our drivers on any Java environment. In writing your own code, however, you are welcome to use any I/O package with which you are familiar. If you choose, several packages which have been used recently at Loyola can be found on the department machines within the folder e:\java\classes\.
Chapter 2 of our textbook includes more advanced details of programming in Java, which many are probably not familiar with. We will cover much of this material in the class as it arises, and some of the highlights are given in the remainder of this handout.
Finally, there are enormously many other tutorials or references for the Java language available, only a few of which are listed in the suggested reading from the course informaton handout. Documentation is also available online, for example through Sun at java.sun.com/docs/.
Let's look at an example involving objects of type String. Consider
the following code:
String a = new String("Hello");
String b = new String("Hello");
The question may arise whether a and b are equivalent.
In the strictest sense, we could write:
if (a==b) {
...
}
For this example, such a test will fail. The expression literally
tests whether or not the two variables are referencing the same object in
memory. Though the words may appear to be the same, there are indeed
two independent String objects sitting in memory.
The more general notion of equivalence is accomplished with the test,
if (a.equals(b)) {
...
}
This test uses the method equals() which must be defined for
all subclasses of Object. In this way, each particular class can define its
own notion of equivalent objects. For the class String, the notion is
what we would expect, that equivalent strings are comprised of the
same sequence of characters. Thus on this example, such a test will
succeed.
Because of this differentiation, you will notice that you cannot assign a primitive value to a variable or parameter which expects a reference to an Object. For example, if you have a class Stack with method push(Object obj) defined, you cannot invoke the method with parameter Stack.push(23).
Of course, we often would like to be able to use an integer value in situation where an Object is expected. For this reason, Java defined "wrapper classes" for all primitive types. For example, to correspond with the primitive type int there is a class Integer, which essentially is a simple class which contains a single int as an instance variable. The class supports two useful functions (among others) which let you convert from the primitive type to the object, and back:
Integer I = new Integer(value);
int value = I.intValue();
Arguments can be specified to a program at runtime, and are often called runtime arguments or command-line arguments. Specifying arguments is something that is done differently depending on the Java development environment you are using, however all such environments should allow you a way to specify arguments.
From the Execution tab, fill in the arguments field, delimited by a
space, such as:
40000 2
To run an applet you generally need to specify the class which implements the Applet, as well as parameters such as the initial height or width of the applet window. Often these values are stored in an .html file which can be used to start an applet.
WARNING: When developing your own applets from source code, a potential pitfall exists if you end up in a situation where a Web Browser is being used to run the applet. Many web browsers try to save time by "caching" much of the information it downloads so that the next time it needs it, there will be no need to reload it over the Internet. Unfortunately, some browsers do this with the .class files which define an Applet. This means that you may end up in a situation where you make a change to your sourcecode, recompile the new code, and rerun the Applet while unbeknownst to you, the browser is still running the old/cached version of your code. This can cause great frustration. I might recommend that try to rely on appletviewer when developing code. If you must rely on the browser, you may need to restart the browser between runs, or worse yet force it to clear its cache and then restart.
You could also set the executor info thru Project -> settings -> execution type -> applet execution. But once you change any property here, your change affects all classes that use that executor.
When you are running an Applet, however, standard output (e.g., that of System.out.println) is not displayed in the main Applet window. Furthermore, if your program crashes, the error information will not be displayed in the Applet window either. Instead, when an Applet is running all standard text output goes to a special window called the Java console. However, you may not see this console unless you look for it. In particular, if you are using Internet Explorer to run Applets, the top-level "View" menu of the browser should contain an entry labeled "Java Console" which you can select to display the console. Similar, using Netscape Navigator/Communicator, you will have to explicit ask to see the Java Console. Which menu to use depends on the version of Netscape. You will likely find it under the "Communicator" menu or the "Communicator->Tools" menus.