newbie: includes/headers  
Index ‹ java-programmer
Author Message
Brad BARCLAY
PostPosted: 2003-8-20 9:42:00 Top
java-programmer, newbie: includes/headers arenaTR wrote:
> Brad:
>
> You're right. thanks for the netiquette reminder.

No problem. Thank-you for taking it so well :).

> Follow-up question: I've seen at the top of java code statements like:
>
> "import something.seomthing.*"
>
> Where is this type of thing found. Or can you give me some background on
> these, they clearly look like include files.

Sure. While similar in syntax to C/C++ style #import statements,
include statements are more of a namespace issue than telling a Java
source file what actual files to include.

The ability to find a particular class (or set of classes) is handled
by your CLASSPATH statement (and by your compiler through its boot
classpath, which automatically knows about the standard classes and
standard extensions). Thus the Java include statement isn't to tell the
compiler where the files should be found, or even what files to use --
it just ensures that the compiler will know what namespaces to
automatically search at compile time.

Java promotes a strong namespacing through the use of /packages/.
Packages are abstract containers in which classes and other packages
(and in some cases resources) reside. For example, most of the core
Java classes live inside the "java" package tree, within various
subclasses that group like classes together. Thus I/O classes are in
"java.io", utility classes are in "java.util", and core language classes
(like the Class class and the Object class) are in "java.lang".

To properly reference an object, you need to refer to it using it's
fully-qualified name, which includes the pagkage name. Thus, if you
want to refer to the InputStream class in the java.io package, you'd use:

java.io.InputStream

As you'll probably realize immediately, this can get really painful if
you have to do this with each and every class your program may
reference. You'd probably want to avoid even using packages if you had
to type all of this out all the time, particularily if your package tree
is deep (for example, in my Open Source Java project, the jSyncManager
(http://www.jsyncmanager.org), we have a class named
org.jSyncManager.API.Protocol.Util.StdApps.AddressAppBlock -- quite the
lengthy name to have to type everytime you need to reference this
class). This is where the import statement comes in.

The import statement allows you to tell the compiler what packages to
search in for classnames where you _don't_ specify the fully-qualified
package/class name. Thus, if I'm working in a class that references
java.io.InputStream 15 times, instead of typing "java.io.InputStream"
all 15 times, I can instead "import java.io.InputStream", and reference
just "InputStream" each time. The compiler will then be able to figure
out what InputStream I'm referencing.

There are some exceptions to this, of course. First off, "java.lang"
is _always_ automatically imported, so you don't have to do this in
every class file you write. The other main exception is that the
current package that your class belongs to will _always_ be searched for
the relevent named class first -- which means you don't have to import
the current package either (you can define what package your class is in
using the "package <name>" statement at the beginning of your source
file, ie: "package org.jSyncManager.API.Protocol.Util.StdApps;").

There is another form of the import statement, one where you don't
specify a specific class name, but instead import _all_ of the classes
in the package. this is done using "*", ie:

import java.io.*;

This will "import" everything in java.io -- thus whenever you reference
a class with just its name (and not it's package), the compiler will
search _all_ of java.io for the classname at compile time.

These namespace issues are important to know, because they're in use
everywhere in Java. There are even rules as to how you should create
your own package names, by using your internet domain name /backwards/,
followed by whatever naming you desire. The actual rules are in section
6.8 and 7.7 of the Java Language Specification. You can read them here:

http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html#73307
http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#40169

One thing to note: some people will tell you that the spec requires
the use of only lower-case characters in package names. This is _not_
true (as you can see in the very first example in the spec). The only
case rules are that the top-level-domain must be lowercase, and by
convention classnames _always_ start with an uppercase character.

One last URL on the subjest -- the JLS's sections on use of the
"import" statement (s7.5.1 and s7.5.2):

http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#26699

Finally, as I mentioned above, I maintain an Open Source Java project.
It's pretty big, but we pride ourselves in keeping our code clean,
organized, and well documented. If you want to peruse it as a large
example (over 150 classes), feel free. You can view the sources online at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jsyncmanager/source/

This will start you just outside the top-level package (which is the
TLD of our domain name, "org"). Feel free to find a source file and
look at its package and import statements.

> Thanks in advance!

No problem. Welcome to the wonderful world of Java :).

Brad BARCLAY

--
=-=-=-=-=-=-=-=-=
From the OS/2 WARP v4.5 Desktop of Brad BARCLAY.
The jSyncManager Project: http://www.jsyncmanager.org


 
 
Index ‹ java-programmer