CSE 4051/CSE5400: Advanced Java Concepts (Fall 2010)

Department of Computer Sciences

General info

Instructor

Office hours

Cross Listing

• cse4051-01 undergraduates
• cse4051-W01 on-line
• cse5400-15 graduate students
• cse5400-W15 on-line

• An abundance of reference material exists on the WWW.
• There are no tests.
• All projects can be submitted on-line and returned by e-mail.
• Questions and discussion can be conducted by e-mail or with the mailing list

Lectures

Class URL

Mailing List

The class has a mailing list on the Florida Tech Sympa list server. Please join, read and contribute to it. Important announcements will be sent to the list. Members can receive all e-mail sent to the list; also anyone can view the latest postings via RSS:

Course Description

We will learn the Java programming language and some of its libraries. Topics include: the core Java language, classes, exception handing, packages, threads, internationalization, GUI, applets, JNLP, networking, RMI, introspection (Java beans), JDBC, and cryptography [maybe].

Prerequisites

If you have not passed cse2010, do not take this course. If you do not like to write programs, do not take this course. Basic knowledge of the Java programming language is assumed, but the most important prerequisite is good programming skills.

No particular Java development environment is going to be explained or required. I use emacs from the GNU project to write Java programs. But other possibilities include:

• Eclipse
• Sun's NetBeans IDE
• BlueJ
• Jedit
• jGRASP

Please note that we review students' code in class from time to time. This is a very effective way of learning how to code (and how not to code), Such code reviews are standard practice in industry, but not usually in classes. If you are offended by this practice, then please do not take the class.

Course Objectives

• Review or quick introduction to syntax and programming in Java.
• More detailed knowledge about OO programming in Java (classes, abstract classes, interfaces).
• Introduction to the new subtype-bounded polymorphism.
• Experience with Java exception handling, threads, and introspection.
• Experience with Java networking, GUI, and JDBC libraries.
• Experience solving medium size programming problems

Reference Material and Textbooks

van der Linden

Peter van der Linden. Just Java 2, sixth edition. SunSoft Press Java Series. Sun Microsystem Press, Mountain View, California; Prentice Hall PTR, Upper Saddle River, New Jersey, 2004. ISBN: 0-13-148211-4, 848 pages.

Lecture Material

Some of the material covered in this class has been collected on the WWW at:

Projects

All programs must run under Java 1.6.0 (that's what will be used in testing). All programs must run on all platforms (don't program OS dependencies into your programs).

The first few projects have an easy and a harder problem. Do one or the other. This is to allow students more computationally challenging problems to warm up with. The later projects are the same for everyone.

Grading

Programs that work, vary enormously in quality. Design, modularity, choice of algorithm, data structures, documentation, readability, style, portability, extensibility, efficiency---these are the factors that go into grading. These are all subjective qualities that cannot easily be quantified. Roughly speaking, the longer it takes the grader to be convinced that the program works, the fewer points the project will receive. Like writing an essay, do not turn in your first, rough draft.

What about internal documentation (comments)? Careful documentation is evidence for careful consideration of the problem and will be rewarded. The key to comments is whether or not they make understanding the program easier. Comments should be grammatically correct, succinct, and add insight to the program. It is not necessary to write extensive general comments---you may presume that grader is familiar with overall description of the project. The most important audience for your comments is you! What comments would you like to see two months after you have written the code? Will you be able to figure out what the code does?

It is not required to use Java Doc (I don't think it is that great for the size of projects we do here.) However, you are welcome to use Java Doc style commenting, if you wish.

All class files are required to begin with a header in a particular format:

/*
 * Author: student name, e-mail address
 * Course: CSE 4051, Fall 2011
 * Project: project tag, short project name
 */

/*
 * Author: student name, e-mail address
 * Author: partner name, e-mail address
 * Course: CSE 4051, Fall 2010
 * Project: project tag, short project name
 */

  * Conversations with Don Knuth helped me figure out how to do IO.
  * The WWW site www.xxx.edu/yyy.html had a good explanation of the Knapsack problem.
  * The client/server example in van der Linden's book (figure 5.4) was the model for my code.

All programs are analyzed for a measure of similarity with other programs, current and past. Students whose programs are very similar to others will receive no credit. This policy is necessary to ensure that students take reasonable action to avoid and prevent plagiarism, and to ensure the proper recognition of independent effort. Without student cooperation the importance of course grades for individuals diminishes, as does the incentive for learning by doing it yourself. Please discourage your peers from cheating. You have more influence than I do. If you have evidence of academic misconduct, you should bring it to the attention of your instructor, Dr. Shoaff, or Dean Kalajian.

Writing a correct program is important, but learning to do it yourself is more important. Do not look at other students' (current or previous) code. Do not spend your time searching for the project solutions on the Internet. Do not allow other students (current and future) to examine or copy your code. Do not post, buy, or sell solutions to the projects. If you need help writing simple programs, then this is not the class for you. Do not denigrate the honest work of other students, by cheating. These rules do not prevent someone from getting help. Asking and answering specific questions on the class mailing-list is a great way to get help quickly and see problems in a different light. Do not ask:

Where do I start with project 8?

For project 8 I read all the input first, before processing any of it.  Is this the best way?

Style

We offer a new service to check your Java programs before turning them in.

Java file Analyze the file (this may take a while):

Misc

Many students make careless mistakes such as using the wrong class name for the project, ignoring the input and output specification, etc. These mistakes make it difficult to evaluate and test the project. It would be nice to screen these problems before the "real" grading, but it is not practical to do so (as we want to do as many different projects over the course of the semester as possible). Please try to get it right the first time. Since attention to detail is an important hallmark of good programmers, projects with such errors will receive very low scores.

Do not leave debug statements in your program; there should be no output that is not specifically requested. Do not devise elaborate debugging mechanisms and leave them in your program (even if they print nothing extra by default), they detract from the clarity of the program. Unnecessary code will result in losing points. This does not prevent you from using assert statements wisely. These statements document the preconditions and postconditions of your code.

Do not prompt for input unless specifically required. Any extra output from your program may make your program fail all test cases. Many times the program output is compared character by character with the correct output (using the program diff).

Essential to readability is consistent indenting. I recommending indenting by 3 spaces--4 spaces wastes too much horizontal white space, and 2 spaces does not leave enough visual contrast. Also try to keep line lengths below 93 characters as that is the amount of space on a line when I print the programs.

You are responsible for producing the most readable program possible. One impediment to readable programs is the tab character. The tab character is interpreted by different software applications differently. A tab character makes it difficult to format your program properly. Since you have no control over how your program will be examined, a tab character in your program may result in loss of readability (and, hence, in loss of points). Take pride in the appearance of the programs you turn in, do not use tabs. Some program development applications use the tab key as an input command, make sure these applications can produce programs without tabs, or use different applications.

Any program with any non-printing characters (e.g., tabs) except for newlines (either NL, or CR followed by NL) will always result in immediate loss of points. Futhermore, if you must eliminate all the problems checkstyle and FindBug find in your code.

A lengthy and detailed guide for the development of well-constructed programs in general can be found in the following book. It is full of practical advice and examples of bad and good program fragments mostly in C and Pascal.

Steve McConnell. Code Complete. Microsoft Press, Redmond, Washington, 1993. ISBN 1-55615-484-4.

A humorous guide to writing poor code can be found in "How To Write Unmaintainable Code" by Roedy Green.

Schedule

Syllabus

Week 1

Introduction, history, hype.

Week 2

Lexical tokens of Java, comments, primitive types, strings. Expressions and statements.

van der Linden, Chapter 3: Primitive Types, Wrappers, and Boxing; Chapter 7: Names, Operators, and Accuracy; Chapter 5: Statements and Comments.

Week 3

Java implementations, bytecode and the JVM.

Information on the net

• Java puzzles
• JavaRanch
• Javalobby
• Roedy Green's Java & Internet Glossary

Quotation