CPE 101:
Fundamentals of Computer Science 1

If you are checking this out before lab, because I promised you some tips that might help you to get started with your first program, then you may or may not need or want all of this in advance. See if this short list of resources is enough; if it's not, then come back here and see if the rest of this Lab appears to help. (If neither seems enough, then pay close attention during lecture and lab during week #2 and consider stopping by during my Office Hours and/or forming a study group with some classmates.)

While you are welcome to read over and think about these activities in advance of Week #2 Lab sessions, please realize that part of your grade for this lab will depend on the extent to which you worked with other classmates during the lab. That is, teamwork is expected: it is actually required!

You will be expected to work with others in these labs. I repeat that even if you finish early in the lab and have completed all work, please help just one other person before you leave the lab. Become familiar with the person next to you, when I refer to "team" or your "team member" I will refer to a person nearby with whom you can easily work.

Once again, there is a checklist for this lab.

As you read through this lab, pay special attention when the lab tells you to note what happens in red like that. All those places require you to write something on the checklist. (Be aware that often, the red caution appears only once, but you are to make multiple notations, following the guidelines that come after the signal.)

In this lab, one thing you will do is to deliberately introduce some syntax errors into a Java program, and learn to recognize the kinds of error messages that each one generates. Before we get to that, however, we will review several activities from last week, adding a few new tricks as we go...

To begin with, as you should have already practiced, start today's lab by creating a temporary folder on your lab machine in which to save today's work. It should be on the S drive.

For the rest of this lab, that location will be referred to as: your temporary folder. Note that these notes were written before the students voted themselves a fee increase, and our labs are much better for the investment by the students. Again, I may often refer to "teams" sharing machines, but this is not nearly so necessary. When "teams" are referred to, make sure you work to some extent with another person nearby, the experience is important. Since each team should have at least two machines on which to work, repeat this step as needed, using a different person's name each time, until each team member has at least one, and possibly two, temporary directories.

Next, download (*) the file Hello.java to each temporary folder. When compiled and executed, this program will output the phrase, "Hello, world!" (on a line by itself in your execution window).

(*) Remember: to download a file linked in to a web page you can move the mouse so it points over the link and then either:

• download it directly (recommended): if your computer (PC) has a two-button mouse, click the right mouse button; if it (Mac) has a one-button mouse, press and hold the mouse button down until a dialog box appears;
• view it first and then save: if your computer (PC) has a one-button mouse, click the left mouse button; if it (Mac) has a one-button mouse, click the button; either way, once you see the page in your browser window, use the File/SaveAs menu item to get a dialog box;

  Once you see the dialog box, navigate your way to your temporary folder, and save the file under the same name as it was given originally (paying attention to case and extension as well as the basic file name).

Now, launch an editor (I will refer you to PFE (referenced here from an old lab at : PFE ref. From within the editor, do the following:

• Use the menu selection File: Open and navigate through until you are able to open your Hello.java file. Then examine this file as downloaded.

Then, in the appropriate DOS window, perform these actions:

• Use the dir command (that is, list the contents of the current directory) to verify that you are in a folder that contains a file with Hello.java as its name. If not, then you missed a step above, so now you still must change directories or do whatever else is needed until you succeed (e.g., change directories as illustrated in Lab #1, use the system Find feature, or even actually re-download Hello.java to the place where it should be).
• Compile this program, by typing javac Hello.java
  • This program should compile without error: what do you see if that is the case? Once again issue the dir command, and note what, if anything, has changed from the last time you listed the contents of the directory.
  • If you do see messages about any errors, note what you had to do to fix them.
• Execute this program, by typing java Hello
  • Notice what happened: what did you see?
  • Once again issue the dir command, and note what, if anything, has changed from the last time you listed the contents of the directory.

---

DOSKEY

Now for a little time-saving trick! You may be thinking that, as you edit and re-edit this file, compile and re-compile, execute and re-execute it, you are going to be typing the same commands over an over again many times. You are certainly welcome to do so, if you want. But our machines (and possibly yours at home) have a feature known as DOSKEY activated that can lead to some very handy shortcuts when you are working in your DOS window:

• Up Arrow goes back one step in your command history and shows the previously typed command. Hitting Up Arrow again goes back one more step.
• Down Arrow goes forward one step in your command history from the (previous) command currently displayed. Hitting Down Arrow again goes forward one more step.
• Left Arrow moves the cursor left one character on the current command line.
• Right Arrow moves the cursor right one character on the current command line.
• Backspace removes one character to left of the cursor on the current command line.
• Delete removes one character at the cursor on the current command line.
• Any regular alphabet, number, or punctuation key inserts the character typed at the cursor position on the current command line.
• Enter executes the command as currently shown (i.e., including any editing you have entered; but you conveniently need not move the cursor to the end of the line).

Before moving to the next part of the lab, experiment to make sure you understand the instructions above. On your checklist, in the blank space at the end, note any discrepancies or concerns.

Note that below I sometimes refer to the "D" drive, but you should probably be doing your work on the "S" drive. Just keep that in mind. Also, my directory structure may not be exactly what you will see, depending on what directory structure you have created. If you have questions, ask.
• If your DOS history does not have your equivalent of these two commands as the last two you entered, then re-enter them by hand this one time:
  D:\temp\YourName> javac Hello.java
D:\temp\YourName> java Hello
• [type up arrow key: shows the java command again, but doesn't execute it]
  D:\temp\YourName> java Hello
• [type up arrow key again: shows the javac command again, but doesn't execute it]
  D:\temp\YourName> javac Hello.java
• [type ENTER - this reruns the javac command]
  [you should simply see a new DOS prompt]
• [type up arrow key]
  D:\temp\YourName> javac Hello.java
• [type up arrow key]
  D:\temp\YourName> java Hello
• [type ENTER - this reruns the java command]
  Hello, world!
• [type up arrow key]
  D:\temp\YourName> java Hello
• [type ENTER - this reruns the java command]
  Hello, world!

---

Learn about Syntax Errors

Now, return to PFE (or whatever editor you are using) and explore the impact of some relatively simple syntax errors. Make sure you have the line number display turned on. This is going to be a little strange, because we are going to deliberately introduce some errors. But, if you insert them, and note both your actions and the consequences, the hope is that you'll start to learn to recognize the kinds of errors that cause different kinds of messages (an important skill in the long run!).

To take notes on your results:

1. In your notebook for this lab, carefully detail:
   • exactly what you changed (e.g., not just that you changed a word, but also what that word was doing on a particular line of the program),
   • exactly how you changed it (e.g., not just the exact typing change, but also what effect that change had on the line),
   • all of the consequences you noticed after re-compiling and even possibly re-executing at this point, and
   • any relevant observations you can make about what you are seeing (e.g., can you explain the results; are you puzzled by them; do they seem consistent or inconsistent with other things you have observed; etc.)
   You should feel free to print out a copy of the file, using the option to print the line numbers as well, and insert this into your notebook to make the references clearer when you later review this (e.g., for a future quiz or test).
2. In your checklist for this lab, your notations must be abbreviated in order to fit in the space provided on the checklist; but be prepared to show your instructor more detailed notes at any time during the lab.
3. Be aware that the checklist is just so I can verify some results from everyone. Your detailed lab notes are the most important part of the lab experience. Both the checklist and spot-checks of your notebook (as well as other files or demonstrations noted in the lab instructions) will be a factor in your grade for any given lab! You should keep your own notes in a way that is meaningful to you, but do keep detailed notes concerning your labs, your own programming experiments both in lab and on your own, and your formal programming assignments.

Note this PFE shortcut: To save a change, click on the diskette icon. The icon is bright red if you've made any changes since the last time you saved: get into the habit of saving your work often! The keystroke-equivalent for this is Ctrl+s (press and hold the Control key while you type the letter "s").

OK, here are some changes for you to try:

• Change the word Hello on line 54 to hello. Save the file. Recompile the program in the DOS window (javac Hello.java). Did you get a compile error?
  1. If yes, record the results in your personal notebook for this lab, and on the checklist you will submit for this lab, next to the number 54.
  2. If no, rerun the program, and record the results as indicated above.
  3. Either way, use the dir command to see and then record the last-modified time and file size of both your Hello.java and Hello.class files.
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Change the word Hello on line 3 to hello. Repeat the testing steps from the first change, above, and record your results both: in your notebook in a way that makes sense to you, and on the lab checklist next to the number 3.
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Change the word Hello on line 58 to hello. Repeat the test process from above. On your lab checklist, document your findings next to 58h.
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Remove the first quotation mark (") on line 58. Repeat the test process from above. On your lab checklist, document your findings next to 58"1.
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Remove the last quotation mark on line 58. Repeat the test process from above. On your lab checklist, document your findings next to 58"2.
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Change the word main to man on line 56. Repeat the test process from above. On your lab checklist, document your findings next to 56.
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Remove the semicolon at the end of the statement on line 58. Repeat the test process from above. On your lab checklist, document your findings next to 58;.
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Remove the right brace } on line 61. Repeat the test process from above. On your lab checklist, document your findings next to 61.
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Make at least two (2) other individual changes, one at a time, and record what you tried and what you found. On the checklist, record your findings next to [*].
• Un-do the last change. Recompile the file to be sure you have fixed any error(s). Repeat any two of the above changes (mine or yours, in any combination) but, this time, make both of them at the same time. Do this twice (i.e., two sets of two different changes.) On the checklist, record your findings next to [**].

Finally, download the file Bugs.java to your temporary directory. Compile it. Note the time (there is a clock in the back of the lab). Use your experience with Hello.java to fix the syntax errors. Recompile the program until there are no compile errors. Note the time again. Run the program.

On your checklist, note how long it took you to fix the errors, and how many you found. (Be accurate. Your lab grade will not depend on how long it took you, but I am collecting data on this task.) Once again, note the clock-time before you proceed with the next step.

Generate a listing of the corrected program, and its output, to be handed in as part of your lab report this week. Follow the instructions below on how to get this, but be sure to note on your checklist the time it took your team to accomplish this part of the lab.

---

Generate Program Hardcopy

At times, you will be asked to generate hardcopy of your programs and their output. Printing the program file itself should be straightforward. Here are some ways to print the the output.

• To generate hardcopy of console screen (text-only) output (needed now), you may use any one of the following methods:
  1. In the execution window (where the output is displayed) use edit-mark and/or edit-copy to copy the block output you want to capture into a buffer. Then, in another appropriate (*) window, use edit-paste to place a copy of the block there. When all the output you need has been captured, use the Print tab to generate your printout. Note that, if your program generates a lot of output, you may have to change the Properties of your DOS window--enlarge the line count in the window's buffer--so that you'll get a scrollbar you can use to review and collect it all.
     (*) What is "another appropriate window"? There are several choices, including but not limited to:
     • Recommended: in a comment block at the end of your source code, which in lab means in that pfe window. If you start the comment with /* (on a line by itself) and end it with */ (on a line by itself as well), then you can paste the sample run in between those comment markers, and add another line identifying it as a sample run.
     • Acceptable alternative: in a separate blank editing window, using pfe, Notepad, or other simple text editor. Using this method, you need not add the comment block markers, but you also don't have the sample run tied as directly to the code that generated it.
  2. Use redirection. This tells your Java program, when you run it, to write its output to a file instead of to the screen. Here's an example:

     Using standard output:	java Hello
     Using redirection:	java Hello > myoutputfile.txt

     Note that, if you use this option, you will not see any output on the screen. But you can use either the standard DOS type command, or an editor, to look at the contents of myoutputfile.txt (or whatever name you choose to use before the .txt extension) to check it out before you do anything with it. What should you do next? The best thing is to follow the same approach as in the previous method:
     • Preferred: using a text editor, copy and paste the contents of this file into a comment block at the end of your code, labelling it as a sample run, or
     • Acceptable: using a text editor, note that this is a sample run from a particular program file, and submit both the source code and this document.
  3. Later on, you will learn how to send output directly to a file. After you have written, tested, and debugged your program, you will modify your program to send its output directly to a file of a given name. Then you can use Notepad or another appropriate editor to view and, if necessary, copy or print the contents of that particular file.
  4. Or, you can use WS_FTP to upload your files to your Central Unix account, compile and run it there. Then you can either use the Unix script utility to generate a run script of the session, or use the File-LogFile option on QVTerm to generate one. If you know how to do this, feel free to do so; if you don't, however, then just use one of the other methods described above. Warning: do not print directly from the QVT/Term application!
• To generate hardcopy of graphical output (for later reference):
  • Use a screen dump utility, such as Super Clip or Capture Eze Pro. Note that these are commercial packages (i.e., they cost $$), and are not currently available in the lab. (Sorry!) For this class, when graphical output is needed in a program, one of the following will be used:
    • Demonstrate your program in person.
    • Use an electronic hand-in process.

---

Compare an Applet to a Program

So far, the Java programs we have been examining have been application programs (or just applications). You run them using the java command. Next, we'll take a quick look at Java applets: they are fun to play with, and you'll find them all over the web, but they are a little harder to work with until you really understand more about Java. (Also, please note that Java and Javascript are two different things entirely. We will not get into Javascript at all.) In this course, we will focus on Java applications, although we will occasionally detour briefly into Java applets.

• Each team member should download the following two file to hi/r own temporary folder:
  • HelloApplet.java
  • HelloApplet.html
    Be careful with the web (.html) pages: if you just click on them, you will initially get a new browser window that may generate an error. Instead, right-click and SAVE the file into your temporary directory.
• In PFE, examine HelloApplet.java, comparing and contrasting it to the Hello.java application program. Note your findings on the checklist.
• Compile HelloApplet.java just as you would an application file.
• Try to execute it by issuing each of the following commands in your DOS window (set to your temporary folder). Do not be surprised if you get an error with one, but not the other: just note the results on your checklist, and see if you can explain anything about why one worked and the other did not:
  • java HelloApplet
  • appletviewer HelloApplet.html
• Close the appletviewer screen.

Repeat the above steps for this pair of files (note in particular the effect of the additional commands included in the program file):

• HelloApplet2.java
• HelloApplet2.html

Now try to compile and execute this applet and note the resulting output:

• Ball.java
• Ball.html

(Here again, note, that there is no .class file available at this site. So the .html page may well show some text, but you won't see the .java Applet running in that window if you just use the URL above. You are to dowload both files, compile the .java file into a .class file, and then view the .html page on your local machine.)

Everyone should do that much. If you are even more curious, and have the time (in lab or on your own outside of class), see if you can understand enough of the applet code to answer the questions on the .html page. (View the .html in a browser window if the questions aren't visible in the appletviewer.)

---

Double-Check Your Lab Work

To receive full credit for this lab, you must submit the following, stapled into a single set of pages (with the Bugs.java file LAST):

1. Complete and submit a checklist: one checklist per individual, with all the sheets for your team grouped together.
2. Hardcopy of your corrected and documented Bugs.java file and its output (one per team, with all team members' names listed).

Some individuals will also be asked to exhibit in the lab setting their individual lab notebook, with the various comments and reflections noted. If you are asked to do so, that will count toward this lab grade. If you get are not asked this time, be patient: your time will come in a future lab!

---

Practice using the handin system...

Practice the process you will have to use to hand in your Programming Assignment #1.

• Try UNIX Login via QVT_term
  1. Watch the demonstration in class.
  2. Read the information sheet on QVT_term.
  3. If you have not yet done so,
     • Create an approriate set of folders and sub-folders (directories and sub-directories) for your work in CSC/CPE-101.
     • Use WS_ftp to move some files to your CSC101 / CPE101 directory in your Unix account. sftp is also acceptable. This can help you as it provides a backup. It is good stuff to know about if you don't already.
• Try UNIX handin
  1. This handin facility should be set up and demonstrated during the second lab of the second week. Check with the instructor.
  2. Read the information sheet on handin.
  3. Try submitting something from your CSC101 Unix directory to the Test folder (and only the Test folder, please!!!) via the handin process.
     Notes:
     • During lab, I will leave a couple other folders open, because that's what you'll have during the normal handin process. If you do something wrong in lab, it's ok IF you tell me, so that I can clean things up before we get to the parts that really do matter!
     • Whatever you put in the Test folder will not be graded, but doing this with one of your lab files will help ensure that you don't get caught at the last minute, trying to submit your homework just under the wire, with no one around to ask for help.

---

Important Reminders

Please remember these rules:

• Use virus-scanning tools regularly! On machines you control (e.g., at home), remember to update the virus tools frequently.
• Always log yourself, and only yourself, into the appropriate places. If you should come across a place where the previous person did not log off before leaving, immediately log that person off, and then log yourself in.
• Always back up your work before you leave the lab. Using WS_FTP to back up files to a folder on your central Unix directory is expected. You may make another backup copy to diskette if you wish (but dead diskettes are not accepted as an excuse for lost or late work!).
• Always delete all your temporary files before you leave the lab.
• After deleting your files, always empty the Recycle Bin on any machine(s) you have been using.
• Always log off of every system to which you logged in.
Copyright © 2000 by Carol Scheftic. All rights reserved. Used by permission.
Requests to reuse information from this page should be directed to Carol Scheftic.
Page created 1 April 2001; last updated 25 June 2001.