Guidelines for Java Oral Presentation and Written Reports


These guidelines assume you will present some Java feature, library class, or other aspect of the Java programming language. Your presentation should explain a topic (usually with short code example(s)).  Do not use terms that have not been used in class without explaining them first.  Be sure that you explain the benefit of the feature you are talking about - that is, what features, functions, capabilities, etc. that it will provide to a Java program.

The basic rationale is this: pretend you are working for a company with a new project and it has been suggested that the feature/technology that you will explain should be used in this project.  The other members of your team don't know anything about this new thing, and you have been assigned to find out about it and give them a summary so they can better decide if it should be used or not.  You assume they know the basics of Java, and you want to tell them the basics of this new feature/technology - including what it is good for, how complex it is, what is needed to get it to work (extra software or databases, or hardware...) and a good introduction to what it looks like at the code level.

If you include code, present a minimal code example - a sort of "hello, world" example for this feature. You may omit lengthy obvious details like laying out and adding components to an Applet, etc.  Do not spend time in your presentation explaining things that your audience already knows.  Bold-facing and numbering important lines of code will help your audience find the specific statements you will discuss.

Your presentation should take about 20 minutes.  You may use an overhead projector or the blackboard.  Computer projector is allowed if you arrange it.

For presenters, prepare a 1 to 6 page handout summarizing your talk for the class, including your code examples.  Make sure there are enough to go around. You could include longer code examples for study.

Note clearly: your job is NOT to impress me with how much you know and how many buzzwords you can use.  Your job IS to impress me with how well you can explain (ie. teach) new material to me and your classmates.  This is for them as much as it is for you. 

Guidelines for a Typical Written Report

If you are asked to submit a report,  the report should be at least 6 pages long in font size 12. The report  should be in your own words. If English is not your native language, do your best.  You will not lose credit for grammatical errors. 

You need to organize the report into sections typically as follows:

Citations (applicable to both the handout and the written report)


At the end of the handout, cite the references you have consulted to prepare the talk (books, magazine articles, Web URLs, etc.).  You should consult and cite at least three different sources. 

In addition, understand that this presentation and the handout should be in your own words. If English is not your native language, do your best.   You will not lose credit for grammatical errors. 

You may quote from other sources, but any direct quotation more than half a sentence long must be cited at the point in your document where the quotation occurs. If the quotation is more than a sentence, it should be indented. (we should be able to see clearly who wrote it, in what article or book or Web site, page number, if any, etc.).  Examples:

1. A single sentence in your own narrative:

Java is fast becoming a mainstream language.  For example, E.R. Harold notes in his Web site  "The College Board, the monopoly that brings you the SAT and the Advanced Placement Tests, has announced that starting in 2003 the AP Computer Science test will include object orientation (about 10 years late); furthermore, the language will change from the current C++ to Java." (

2. A paragraph:

These naming issues may appear superficial at first -- "cosmetic", as programmers sometimes say. But do not forget that one of our eventual aims is to provide the basis for powerful, professional libraries of reusable software components. Such libraries will contain tens of thousands of available operations. Without a systematic and clear nomenclature, both the developers and the users of these libraries would quickly be swamped in a flood of specific and incompatible names, providing a strong (and unjustifiable) obstacle to large-scale reuse.

Naming then, is not cosmetic. Good reusable software is software that provides the right functionality and provides it under the right names.

--Bertrand Meyer
Object Oriented Software Construction, 2nd Edition, p. 128

Alternately, you could use endnotes and place the actual citation at the end of your document.

Please Note: Failure to do this is called plagarism and is considered to be academic misconduct.


General Suggestions

  1. Don't choose too big a topic.  You only have 20 minutes.  If the topic is large, you will not be able to go into too many details.
  2. Don't talk too fast.  Speak clearly.  Use overhead foils to support your words.
  3. Prepare overhead foils with the main points only - not every single word in your handout (or your talk).  Make the font big enough for people in the back of the room to read.
  4. You have the advantage of knowing what your audience knows about Java.  Don't waste time telling them things they already know.
  5. Practice your talk out loud at least once - with a friend listening, if possible. 
  6. Make sure you don't go over the time limit.
  7. If you use the blackboard, be sure you know exactly what you will write.  Don't make it up as you go along.  Understand that writing on the board takes a lot of time, and that it is difficult to write large enough and neatly enough for everyone to read.
  8. Don't use words that your audience does not know unless you define or explain them.   For example: "RMI marshalls the arguments to a method call before..."   What does "marshalls" mean?
  9. Don't simply copy sentences from some source into your handout (even if you cite them) if you can't explain in different words what they mean.
  10. In particular, don't use comparisons that you can't explain: "Servlets are like Applets without a face"  - what does that mean?  That servlets are applets without a gui?  No, not really... 

Your Audience

Be aware of your audience's needs.  In particular:

1. Set up the overhead projector or computer in advance.

2. Prepare and pass out enough handouts before you begin your talk.

3. Check the lighting and be sure that it is not too bright for people to read the screen, but not too dim for them to take notes.

4. Be sure your slides can be read at the back of the room. This involves focus and size. (See point 3 above)

5. Speak loudly enough to be heard in the back.  Don't talk too fast.

An Outline of a Typical Presentation

1. Give a brief (one minute) summary of what your presentation will cover.

I will describe the RandomAccessFile Class and some of its most important Methods, and then show how it can be used in an Application to implement a simple Relative Record File Access Method.

2. Describe what the language feature will allow a program to do.

The RandomAccess File class allows a program

Using these facilities, we can implement direct access file operations similar to a VSAM RRDS or KSDS. (The latter would require a lot of work.)

3. Explain what you need to do in a program to implement a simple version of this feature.

4. Present some simple code that illustrates the feature.

As an example, present two demonstration programs that:

In each of these demo programs, use pseudocode or indicate via comments the details not relevant to the File operations.