CSE 4051: Advanced Java Concepts (Spring 2008)

Department of Computer Sciences

General info

Instructor

Office hours

Lectures

Class URL

Mailing List

The class has a mailing list on the Florida Tech new 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 lastest 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, servelets [maybe] 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. Some Java development tools suffer from problems that adversely effect this class:

1. they take as long to learn as the language itself,
2. they produce programs that don't run in other environments, and
3. they make it difficult to control the appearance of the program.

• 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 clases.

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 SBN: 0-13-148211-4, 848 pages.

Lecture Material

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

Projects

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

Grading

Programs that work, vary enormously in quality. Design, modularity, choice of algorithm, data structures, documentation, readibility, 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, Spring 2008
 * Project: project tag, short project name
 */

/*
 * Author: student name, e-mail address
 * Author: partner name, e-mail address
 * Course: CSE 4051, Spring 2008
 * 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 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 bulletin board 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

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 programers, 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.

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 drastic loss of points.

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 Tyeps, 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