Assignments | Grading | Submitting | Getting help | Environments and requirements | Hints and Kinks
Assignments are not accepted after the due date.
Assignments are graded on:
Whenever it is suggested you develop an assignment in stages (and even when it isn't suggested), get as many stages running properly as you can. Document at the beginning how many stages it does properly. Your program may also contain code, commented out if necessary, to document your efforts to complete the assignment.
There are several things to do for every assignment. It is suggested you review this list every time you hand in an assignment.
If you see an instructor or AI for help with an assignment, bring your program both on floppy disk and printed copy, or if you are unable to get past the design stage, bring your design notes (however tentative). If you have a problems indicated by an error message, also bring a printed copy of the error message, and locate in your program code the lines referred to in at least the first error message (the emacs command M-x goto-line is helpful for this). Hint 9 below explains how to print error messages. If you have a runtime problem, the floppy disk you bring should contain all .class (as well as .java) files, and the html file if the assignment is an applet.
Do not expect quick fixes. We are not just a debugging service. After a problem has been located or a reasonable debugging technique has been found that will bring you closer to solving your problem, you are expected to implement the improvement on your own and make an effort to resolve the next bug, if there is one. Of course you may return if you have made such an effort and are stuck again. But we will not resolve multiple bugs in one advising session. You would learn little that way. Obviously advising cannot be relied on to resolve multiple bugs just before an assignment is due, and until your program is working you have no way of knowing how many errors it contains. So the only safe approach is to start work early and plan on completing the assignment well before it it due.
You must have a computer account on the nations cluster: 20 workstations running Solaris, Sun's version of the Unix operating system. If you do not already have a nations account, generate one using the UITS account creation system, for which you must have a network ID and password. If you do not know this password, you will have to go to the UITS office in the Union. How to use the nations environment will be explained during the lab session of the first week. We will be using Java 1.1.
Though the nations cluster is in the Geology building (room 226), you can use a telnet program (called host presenter on Macintosh) or other means to access nations from any Internet computer, including any of the STC labs (Student Technology Center labs: public clusters run by the university). When asked for a machine to connect to, just enter nations (or if that does not work, use nations.ucs.indiana.edu). If you use an off-campus ISP, you cannot connect directly to nations, but you can get an account on a steel cluster machine, telnet to steel, and then telnet from steel to nations.
All programming assignments must be handed in electronically on the nations cluster using the c212handin program. See the handin tutorial. Never email an assignment submission to any instructor. Not being able to use the h212handin program, machine downtime, not being able to connect to the IU network from home, and so on, are not acceptable excuses for failing to submit assignments on time.
You are free to do the assignments in whatever environment you like, provided your programs run on the nations cluster. There are several options: one of Java's big advantages is its platform independence. Nevertheless, Java program portability may be less than perfect and you are responsible for your programs compiling and running properly on the nations cluster.
The most general way to move files from one internet machine to another is ftp (file transfer protocol). If you develop your programs somewhere else, this is probably the best way to move your files to nations. See the ftp tutorial prepared for this course.
Program development, particularly in a language as complicated as Java, is easier using an IDE (integrated development environment) that integrates in one system support for editing, compiling, execution, debugging, and often other programming tasks such as documentation and file management. It takes time to learn to use an IDE, but they pay back this time and more in the long run. Some Java development options include:
emacs
reference card that is best printed back-to-back.On-line material of use in this course include a Java tutorial by Sun and documentation of the Java 1.1 APIs. The latter, or some other comprehensive Java 1.1 API documentation, is necessary for this course. It is strongly suggested that you download the JDK 1.1 documentation in HTML form (under 12MB), which includes the API. Visit the api/packages.html file of this download with your browser and bookmark it. This will allow you to look up API information quickly. The JDK1.1 documentation page includes links to other aspects of Java, such as development tools (java, javac, javadoc, appletviewer, etc.) and the official Java specification and the JVM specification (which doe not include the APIs and goe way beyond this course). Likewise, there is a large set of Java 2 documentation.
For general help with Unix, there is a very basic guide, with DOS comparisons, and a locally-mirrored fairly comprehensive reference (with a concepts menu), all selected from a great page of system software tutorials, and a makefile tutorial.
After you create a class file (e.g. compile
with javac successfully), you can run your program using the java
command flag -Djava.compiler=NONE to be able to see the line
numbers of the problematic lines at run time, if there are any.
For example:
% java -Djava.compiler=NONE Foo
will run the program "Foo.class" and give the line
numbers of the runtime errors.
The browser remembers classes it has loaded. Reloading a page does not reload the classes of applets it refers to. You may have to exit the browser and enter again to reload the class files, though in Internet Explorer ctrl-F5 reloads both the html page and the classes it references.
You cannot run an applet meaningfully on nations without going physically to the nations lab (unless you have physical access to a computer with X-windows client software, which you probably do not). Instead, after compiling your program on nations using make all, you can ftp the .class file(s) and html file from nations to a computer with JDK1.1 installed (such as an STC PC lab computer or perhaps a personal PC) on which you can test your applet. Put the HTML file and the class file(s) in the same directory. The applet can be tested using any web browser that uses JDK1.1, such as Netscape or Internet Explorer on STC PCs, or the JDK1.1 applet viewer using the command
appletviewer applet.html
in the directory with the applet.html and assignment class files.
4. java.lang.noSuchMethodError
Do not define a constructor for an applet class. The default constructor (no argument, does nothing) is the right one. If in defining an applet you provide a constructor that takes one or more arguments there will be no default constructor of zero arguments and you will get a java.lang.noSuchMethodError from Netscape or appletviewer. Strangely, Internet Explorer will just ignore your applet constructor.
5. Applet graphics
getGraphics() should be used in init(). It will not work in a constructor or an initialization expression that is part of a field declaration. The right graphics object does not exist at the time the applet object is created, but does exist by the time init() is called.
5. Detecting runtime errors and seeing character output
A correct Java program should not return any errors or exceptions under any circumstances. If it does, a full report is printed on the standard output stream. These full reports include the name of the method that was running when the error or exception occurred and the line number, as well as where that method was called from, and so on. This is useful information in debugging Java programs. Anything printed on System.out also goes to the standard output stream.
In a Java application or an applet run by appletviewer, the standard output stream is seen in the Unix or DOS command window in which the application, Java interpreter (java command), or appletviewer was invoked. Internet Explorer and Netscape Navigator partially report errors, but not exceptions, in the one-line status bar at the bottom of their screen. Explorer allows you to see the standard output stream via View->Java_Console, but this only works if Tools->Internet_Options->Advanced->Java_VM->Java_console_enabled is selected (which it is not in the standard STC machine configuration). It says that you have to restart the machine after selecting this, but all you have to do is exit Explorer and start it again. Unfortunately, Navigator 4.5 empties the Java standard output stream into a bit bucket (you cannot see it). This means Navigator is unsuitable for testing applets, and if you use Explorer you should always view the Java console.
6. Browsers may refuse to run Java at all (for security reasons)
Though this is not a problem with STC machines, it is possible that Java may be entirely disabled in Explorer with Tools->Internet_Options->Security->Java->Java_permissions->Disabled. If so, select another permission setting. (If someone knows if Java can be disabled in Navigator and how, let me know.)
7. Appletviewer does not recognize key input properly
This is a serious problem on Windows machines (among others). Similar problems exist with some Netscape environments, though not on STC Windows machines. However, Netscape suffers from the problem noted in 5 above. So if necessary use Explorer on STC machines to test keyboard input applets.
8. Explorer confused by FTP
Using Microsoft's visual ftp application, if you double click on an html file in a remote file system view it automagically launches Internet Explorer to view the file; but this is of no use for testing applets. If an html file contains an applet tag without a codebase attribute it is assumed that the Java class named by the code attribute is in the same directory as that containing the html file, as indicated by the local file address or URL of the html file. But the html file viewed via an FTP launch has niether a URL or a local file association, so the applet cannot be loaded. The solution is to use FTP to copy the html and Java class file(s) to the same directory on the local machine, and then view the html file on the local machine as a separate operation using an appletviewer or web browser of choice.
9. Viewing and printing error messages
The Java compiler may produce a number of error messages that scroll out of a telnet window before they can be viewed. Since compilers may be confused by earlier errors, later errors may go away when earlier errors are corrected. So the early errors that scroll off the screen are the ones you most need to see. Also, if you ask for help with an error, you should bring a printed copy of the error message. A solution to these problems is to redirect the standard error output of the program generating the error message(s) to a temporary file using the >& operator ofo the Unix shell. For example, after executing % javac BadClass.java >& errorMsg, the file errorMsg will contain the the error messages generated when compiling BadClass.java. This works with all Unix commands, including java, javac, jdb, and make. This error output file may then be printed (after FTPing it to the local machine if necessary), or viewed using an editor or the Unix more command. If a file for printing is not needed, the Unix standard error output pipe operator, |&, may be used with more. For example, % javac BadClass.java |& more.
10. Handing in all .java files.
If the Java compiler is compiling a class that refers to another class that is not compiled, it will automatically compile the other class also before it quits. This convenience can lead to an incorrect handin being undetected. If the makefile sources list does not include a file in your program, it will be compiled anyway with make all as long as the starting file (which presumably refers to all the others directly or indirectly) is in the sources list. But if you use make handinApplet only the files in the sources list are handed in, so your program will not work when compiled by the grader. So be careful that your sources file is complete if you use handin. handinpro does not have this problem.
More hints and kinks will appear in this space in the course of this course.