Java程序辅导

CITS4211: Artificial Intelligence
Getting Jiggy with Xcode
Aim
This exercise sheet introduces you to Java development using the integrated develop-
ment environment (IDE) Xcode.
Getting Started with Xcode
Starting Xcode
In the dock at the bottom of the screen you should see this symbol for 
launching Xcode. If you don’t see it, locate it in the Finder under 
Developer/Applications and drag it onto the Dock.
Click on the launcher. 
Creating, Compiling and Running a New Project
Follow the instructions (with the exceptions below) at The Java Tutorial’s “Hello World for 
Mac OS X” page at:
http://bioportal.weizmann.ac.il/course/prog2/tutorial/getStarted/cupojava/mac.html
The latest version of Xcode has changed a little so you will notice a few differences. In 
particular there are a couple of things you should  know.
Create a Source File
When you create a new application you should choose the “Java Tool” option, which su-
percedes the “Ant-based Jar Application” option shown in the tutorial.
When you select the Java Tool, a window will open to select where you want to save the 
project. The project name will be the same as the directory name. Navigate to your 
CITS4211 directory (created in the previous lab) - to make this easier click the down tri-
angle beside the “Save As” field. Click New Folder to create a subdirectory, and call the 
subdirectory Lab00. Select that subdirectory, then type in the project name (“Hel-
loWorldApp”).  
Compile and Run
The console window no longer pops up by default. To see the output of your program se-
lect Run|Console.
The quick tutorial takes you through the basics of creating an Ant-based jar application 
(more on this later), and building and running it. You should now have your first working 
application in Xcode!
Customising Xcode
In the above tutorial you are asked to edit the program in a little editor pane that you pull 
up from the bottom of the project window. This is constraining in practice and you will 
want to be able to use multiple editor windows.
You can open an editor window for your hello world app by double clicking it in the file 
list, or by clicking the triangle next to ‘src’ and double clicking your java file in the result-
ing list. 
In the top right corner of the editor window that opens, you will see an icon that says 
“Ungrouped” or “Grouped”. Grouped opens subsequent files in the same window, 
whereas ungrouped will open subsequent files in new windows. The former may be useful 
if you have very limited screen space, for example on a small laptop, but in general can 
seem confusing as files “disappear”. Set this to “Ungrouped”.
There are many other preferences you can set, including a couple of useful ones that you 
should do now. Go to Xcode Preferences | Indentation. Deselect “Insert tabs instead of 
spaces” (this will help if you later wish to edit the file with another editor). Set Tab width 
and Indent width to 2. Also check “Syntax aware indenting”, and set “Tab indents” to 
“Always”. Then hit “Apply” or “OK”.
Now return to your hello world java program. Place the cursor on the word “void” in the 
first line of the main method. Hit C-f (-f) - notice how those “emacs” commands 
you learnt also work in Xcode! Hold C-f until the cursor is at the start of the next line of 
code. Now press ‘tab’. You should notice the code adjusted so that it is indented two 
spaces from the line above. The editor is “context aware” - it knows that the main 
method is subordinate to the class statement and should be indented. Now press ‘tab’ 
again. If you have followed the above instructions correctly you should notice no change - 
the editor knows that it is not appropriate to indent any further. Similarly place the cursor 
after the ‘{’ and press ‘return’ - the next line should automatically be indented to the right 
place. (This can be a useful early debugging feature - if the editor doesn’t indent a line to 
where you expected, chances are you missed out a closing bracket or similar.)
Compile Error Highlighting
Before we leave Xcode lets take a quick look at an example facility Xcode provides to 
help with debugging. First go to the Xcode preferences and choose the “Building” pane. 
Under “Build Results Window” set “Open during builds” to “On Errors or Warnings” and 
click “Apply”. Then go to the “Text Editing” pane and tick “Show line numbers”, and click 
“OK”.
Now open your hello world java file and change the word void to vod. Pretend you 
weren’t tipped off by the change of colour of the word, and click “Build and Go” again. 
(You may notice the code still executes correctly. This is a good reminder that you should 
always save your code before building. You can quickly save it by hitting Command-s.) 
Notice that a build results window opens listing two errors in red. Click on “cannot find 
symbol”. You should see your java file open with the erroneous line highlighted, ready for 
you to fix. You can also access the build results window by clicking the red cross that ap-
pears when there are build errors.
It is these kinds of conveniences that make GUI development environments nice to use 
(in fact there are many more debugging facilities at your disposal). Remember though that 
the same basic functionality can be achieved in different ways, including from the Unix 
command line. A simple example of this follows.
Behind the Magic: Part I
We will look in more detail later at how Ant-based builds work in Xcode and how you can 
tailor them to your needs. Before we go on, however, have a look at the Xcode project 
tree using Finder to see where the various files are located.
You will see that the directory your project is in contains the project file, with extension 
‘.xcodeproj’, as well as the file build.xml and a resources directory containing the 
file Manifest. We will see what these do later. If you click on the src (short for “source”) 
directory, you will see it contains the java sources for your project. Now click on the bin 
(traditionally short for “binaries”, tho in this case they are actually byte codes) directory. 
This directory is where the java executables or class files are placed when you build your 
project from the sources. Finally, have a look in the dist (short for “distribution”) direc-
tory. This is where the final product of the build is placed (ready for distribution to your 
clients). In this case the final product is a jar file (short for “java archive” - a compressed 
archive of the class files). You can also run the product from this directory.
Now open up a new shell (Terminal window - see the MacOSX lab sheet) and change di-
rectory to the project directory, and then to the dist directory. List the contents and you 
will see HelloWorldApp.jar. Have a look at the contents of the jar file with the com-
mand:
% jar -tf HelloWorldApp.jar
To see what the ‘t’ and ‘f’ flags stand for, have a look at the jar command’s man page (see 
the MacOSX lab sheet). You should see a manifest, and the class files (in this case just 
one). Now run your program using:
% java -jar “HelloWorldApp.jar”
Once again, take a look at the man page for the “java” command to see where this incan-
tation came from. In fact, this is the same command Xcode uses to run your code! (In the 
next lab sheet we will look at how executables are defined in Xcode.) 
The moral: in a Unix-based system, you can usually look behind the “magic” of the GUI to 
understand what is really happening at the operating system level.
Continuing on..
Later you may wish to continue on for the rest of the trail in the Java Tutorial from above. 
You will find that it refreshes some of your Java knowledge, and finishes with some self-
test questions and answers.
Behind the Magic: Part II
One reason that development environments are useful for working on larger software pro-
jects is because they handle many of the other tasks that are required in addition to sim-
ply compiling a program, such as creating directories, placing the right build products in 
the right places, creating deliverables for development and production builds, cleaning 
up, etc. In many development environments the way in which this is done is hidden from 
the user, who is required to tailor the process by setting various parameters.
Long before the advent of integrated development environments, these same tasks were 
necessary, but were done using scripts - the most widely used being a utility known as 
make. A more recent version, developed specifically for Java, is the Apache opens source 
Ant tool. Have a read through the description of Ant (and the inherent evils of Makefiles). 
One of the nice things about the Xcode projects we are using is that they are transparent 
- the build is simply handled by calling Ant.
The tasks carried out by Ant are specified by an XML file called build.xml. Find this file 
in your own project and double click to open it up. You will find that its fairly self-
explanatory or “human-readable”. You can find out exactly what commands are available 
and what they do by looking at the Manual at the Ant website.
You can specify exactly what should be done on a build (for example when you hit 
Xcode’s Build and Go button) simply by modifying the build file. Try modifying your own 
build file so that when you build, in addition to compiling your code, it also automatically 
(re)generates the javadoc documentation for your code, and places it in a directory in 
your project called “doc”. (The build should also create the directory if it doesn’t already 
exist.)
Of course one advantage of Xcode using Ant builds is that you can take a copy of your 
project home and work on it, even if you don’t have Xcode. You just need to ensure Ant is 
installed on your machine and run Ant directly.
Cara MacNish
CSSE @ UWA