DOC PREVIEW
Berkeley COMPSCI 164 - Basic Compilation: javac and gmake

This preview shows page 1-2-3-4 out of 12 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 12 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Compilation and InterpretationWhere `java' and `javac' find classesThe interpreter's classesThe compiler's classesMultiple classes in one source fileCompiling multiple filesArchive filesThe make utilityBasic Operation and SyntaxVariablesPhony targetsDetails of actionsIncluding makefilesUNIVERSITY OF CALIFORNIADepartment of Electrical Engineeringand Computer SciencesComputer Science DivisionCS164 P. N. HilfingerSpring 2008Basic Compilation: javac and gmake[The discussion in this section applies to Java 1.5 tools fr om Sun Microsystems. Toolsfrom other manufacturers and earlier tools from Sun differ in various details.]Programming languages do not exist in a vacuum; any actual programming done in anylanguage one does within a programming e nv i ronment that comprises the various programs,libraries, editors, deb uggers, and other tools needed to actually convert program text intoaction. This document discusses the tools that translate programs into executable form andthen execute th em.1 Compilation and InterpretationThe Scheme environment that you used in CS61A was particularly simple. It p rovided acomponent called the reader, which read in Scheme-program text from files or commandlines and converted it into internal Scheme data structures. Then a component called theinterpreter operated on these translated programs or statements, performing the actions theydenoted. You probably weren’t much aware of the r eader; it doesn’t amount to much becauseof Scheme’s very simple syntax.Java’s more complex syntax and its static type structure (as discussed in lecture) requirethat you be a bit more aware of the reader—or compiler, as it is called in the context ofJava and most other “production” programming languages. The Java compiler supplied bySun Microsystems is a program called javac on our systems. You first prepare programsin files (called source files) using any appropriate text editor (Emacs, for example), givingthem names that end in ‘.java’. Next you compile them with the java compiler to createnew, translated files, called class files, one for each class, with names ending in ‘.class’.Once programs are translated into class files, there is a variety of tools for actually executingthem, including Sun’s java interp reter (called ‘java’ on our systems), and interpreters builtinto products such as Netscape or Intern et Explorer. The same class file format works (or issupposed to) on all of these.In the s implest case, if the class containing your main program or applet is called C, thenyou should store it in a file called C.java, and you can compile it with the commandjavac \{$C$\}.java12 P. N. HilfingerThis will produ ce .class files for C and for any other classes that had to be compiled becausethey were mentioned (directly or indirectly) in class C . For homework problems, this is oftenall you need to know, and you can stop reading. However, things rapidly get complicatedwhen a program consists of multiple classes, especially when they occur in multiple packages.In this document, we’ll try to deal with the m ore straightforward of these complications.2 Where ‘java’ and ‘javac’ find classesEvery Java class resides in a package (a collection of classes and subpackages). For example,the standard class String is actually java.lang.String: the class named String that residesin the subpackage named lang that resides in the outer-level package named java. You u s ea package declaration at the beginning of a .java source file to indicate what package it issupposed to be in. In the absence of such a declaration, the classes produced from the sourcefile go into the anonymous package, which you can think of as holding all the outer-levelpackages (such as java).2.1 The interpreter’s classesWhen the java program (the interpreter) runs the main procedure in a class, and that mainprocedure uses some other classes, let’s s ay A and p.B, the interpreter looks for files A.classand B.class in places that are dictated by thin gs called c lass paths. Essentially, a classpath is a list of directories and archives (see §5 below for information on archives). If theinterpreter’s class path contains, let’s say, the directories D1and D2, then upon encounteringa mention of class A, java will look for a file named D1/A.class or D2/A.class. Uponencountering a mention of p.B, it will look f or D1/p/B.class or D2/p/B.class.The class path is cobbled together from several sources. All Sun’s java tools automaticallysupply a bootstrap class path, containing the standard libraries and such stuff. If you takeno other steps, the only other item on the class path will be the directory ‘.’ (the currentdirectory). Otherwise, if the environment variable CLASSPATH is set, it gets added to thebootstrap class path. In past years, our standard class setup had ‘.’ and the directorycontaining the ucb package (with our own special classes, lovingly concocted j ust for you),which we set up with the commandsetenv CLASSPATH .:/home/ff/cs61b/lib/java/classes(the colon is used in place of comma (for some reason) to separate directory names). T heinterpreter and compiler would then find the definition of a class such as ucb.io.StdIO in/home/ff/cs61b/lib/java/classes/ucb/io/StdIO.classThese days, we use archive files instead, as described below in §5.2.2 The compiler’s classesThe compiler looks in the same places for .class files, but its life is more complicated, becauseit also has to find source fi les. By default, when it needs to find the definition of a class A,Basic Compilation: javac and gmake 3it looks for file A.java in the same directories it looks for A.class. This is the easiest caseto deal with. If it does not find A.class, it will automatically compile A.java. To use thisdefault behavior, simply make s ure that the current directory (‘.’) is in your class path (asit is in our default setup) and put the source for a class A (in the anonymous package) inA.java in the current directory, or for a class p.B in p/B.java, etc., using the commandsjavac A.javajavac p/A.javarespectively, to compile them.It is also possible to put source files, input class files, and output class files (i.e., thosecreated by the compiler) in three different directories, if you really want to (I don’t think we’llneed this). See the -sourcepath and -d options in the on-line d ocumentation for javac, ifyou are curious.3 Multiple classes in one source fileIn general, you should try to


View Full Document

Berkeley COMPSCI 164 - Basic Compilation: javac and gmake

Documents in this Course
Lecture 8

Lecture 8

40 pages

Load more
Download Basic Compilation: javac and gmake
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Basic Compilation: javac and gmake and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Basic Compilation: javac and gmake 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?