230 likes | 384 Views
Java Classes. How does it find them?. Basic Approach. Different from c++. Uses header files for prototypes uses INCLUDE variable to indicate location of .h files not in system directories libraries are stored elsewhere and located by LIB variable Java uses only the java source.
E N D
Java Classes How does it find them?
Basic Approach • Different from c++. • Uses header files for prototypes • uses INCLUDE variable to indicate location of .h files not in system directories • libraries are stored elsewhere and located by LIB variable • Java uses only the java source. • No prototypes • uses a more complex naming/search scheme • details follow
C++ #include “myclass.h” void main () { myclass x; ….. } public class myclass() { int a; int b; public: myclass(); ~myclass(); ….. } myclass.cpp How does c++ find the header files? .. Searching the “include” path. myclass.h
No “include” in Java! Only one file!
Java connects files with“package” and “import” • package • Groups class definitions together for privileged access, lets other classes in the package see more details • Generally a way of grouping a set of library routines • import • Very similar to include, but there is no include file counterpart • Identifies all packages OTHER THAN the one that class is in, from which this class needs access
Directory location is important • Classes in the same package are stored in directory hierarchies to help import find the files. • These directories also aid in resolution of ambiguous naming problems. • More later….
Two classes defined to be in package first package first; class classA { classB b = … new classB(); } classA.java Being declared in the same package will allow each class to access each other without extra work. classA using classB package first; classclassB { // most of your code } classB.java
Two classes in different packages! packagefirst; import second; class classA { classB b = … new classB(); } classA.java Being declared in the different package will require the use of import to access each other. packagesecond; class classB { // most of your code } classB.java
Package names • Can be dotted to show directory organization • Example • math.algebra.sets • math.calculus.integration • math.calculus.differentiation import math.*; or import math.algebra.sets; math algebra calculus differentiation integration sets
Example Format of a file package com.myplace.mygroup.myclass; // OPTIONAL import java.io.*; // OPTIONAL import anotherclass.mathlib.vectors; // OPTIONAL public class thisclass { // most of your code } So let’s examine this one element at a time.
package com.myplace.mygroup.myclass; // OPTIONAL import java.io.*; // OPTIONAL import anotherclass.mathlib.vectors; // OPTIONAL public class thisclass { // most of your code } • Provides a solution to the problem of generating a unique package name • Groups classes for more convenient use of related classes. • Defines the package in which a class is placed • Helps to define the directory in which the compiled file will be placed • Only ONE package statement per file because a class can only be in a single package. • If no package, class is considered to be in defaultpackage.
Unique package names • Lots of programmers in the world • Significant opportunity for redundant naming of classes • General principle -> namespaces • Here, classes are grouped in packages to provide a means to give uniqueness to name • two programmers name the routine x • com.mycompany.billy.io.x • com.mycompany.sam.io.x • x can be uniquely identified by qualification
Package name -> Directory name • A package name dictates the directory structure in which class is stored. • Does NOT indicate the complete path but a path that exists somewhere. • E.g., com.mycompany.billy.io.x / ? It DOES provide a unique name to use in accessing x! bin home com company sam billy io io x x
package com.myplace.mygroup.myclass; // OPTIONAL import java.io.*; // OPTIONAL import anotherclass.mathlib.vectors; // OPTIONAL public class thisclass { // most of your code } • Directly related to packages • Used to provide a shorthand • Used for accessing OTHER classes NOT related to the package statement (if it exists in the file) • CAN have import without package and vice versa. • While they are related, the use of the use of them in the SAME file is typically independent/coincidental • package defines the package THIS class is IN • import used to ease USE of classes in OTHER packages
import just makes is easier! • The names have a tendency to be long in order to be unique • import lets you use a shorthand for qualification. • Like “with” in pascal to avoid listing all substructures in a record to access names. • Example follows:
How to define the CLASSPATH Using a unix example, the code references “com..” In order to reference com.company.billy.io.x the CLASSPATH must include /dev, everything up to but not including com. / bin develop home com company sam billy io io x x CLASSPATH= /lib/java;/develop
What can one import access?import examples com // can’t access ANY classes import com; company // can’t access ANY classes import com.*; logo billy organization // can access // logo and organization import com.company.*; io x y // can access only x import com.company.billy.io.x; red - directories black -> classes
Which x? package com.myplace.mygroup.myclass; // OPTIONAL import com.mycompany.sam.io.x; public class thisclass { // most of your code x thisx = new x; } Here x can be referenced in shorthand and is uniquely defined to be the x in the io package defined by sam. This also emphasizes disconnect between the package in the package statement and the package in the import.
What about * in import? package com.myplace.mygroup.myclass; // OPTIONAL import com.mycompany.sam.io.*; public class thisclass { // most of your code x thisx = new x; y thisy = new y; } * indicates that you can shorthand any class in the package. In this example, y is considered to be in the same io package and can be accessed in the same manner as x (shorthand).
So how does java figure outEXACTLY where to put package? • We used a ‘?’ in directory to indicate it was not known where. • Determined at compile time • uses -d option to say where • E.g. • javac -d /project1/devstuff thisclass • creates the package and the com.mycompany… directory under /project/devstuff • /project/devstuff/com/mycompany/mygroup/...
Now how does it find the class when it compiles the program? • 1. Look in java system class directories • 2. Look in extensions directory (???) • 3. Look in CLASSPATH. • Environment variable • default is current directory • unix example: .:/project/dev/java:/home/dgame/611 • current directory first • then /project/dev/java • and lastly /home/dgame/611
Confusion • Search of path is documented in contradicting manner • O’reilly Java in a Nutshell: • “The interpreter always appends the location of the system classes to the end of the path specified by the environment variable.” • other references indicate it searches in the system first. • Regardless, there can be no naming ambiguity
What if there are 2 classes with the same name? • Compiler will alert you if there are multiple names in the path AND no means to resolve the ambiguity (import) is coded. • Using import resolves which one you are referencing. • If error message occurs, use more specific reference to the class.