wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes java.awt.*; and java.awt.event.* Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "java.awt.*; and java.awt.event.*" Watch "java.awt.*; and java.awt.event.*" New topic
Author

java.awt.*; and java.awt.event.*

Mario Levesque
Ranch Hand

Joined: Nov 01, 2000
Posts: 51
Hi guys,
I wrote the small application below while learning events.
The application now works, however, for some reason I get compilation errors if I do not include the extra "import java.awt.event.*;" at the top. This seems strange because I already have import java.awt.*; which is more general.
Can anybody explain why the specific one with the extra ".event.*;" is required???
Cheers
Mario
---------------------------------------------
import java.util.*;
import java.applet.Applet;
import java.awt.*;
import java.awt.event.*; //this one is also needed!!!
public class EventTest extends Applet{
//2ndtechnique//public class EventTest extends Applet implements ActionListener{
Button monbouton1;
public void init() {
setLayout(new FlowLayout());
monbouton1 = new Button("Action");
MyActionListener listenerVar = new MyActionListener();
monbouton1.addActionListener(listenerVar); //assigning listener to the button
//2ndtechnique//monbouton1.addActionListener(this);
this.add(monbouton1); //using "this" is not required but shown anyways
}
//2ndtechnique//public void actionPerformed(ActionEvent e) {
//2ndtechnique// if (e.getSource() == monbouton1) {
//2ndtechnique// System.out.println("Statement action in the listener");
//2ndtechnique// }
//2ndtechnique//}
}
//This is the listener
class MyActionListener implements ActionListener {
public void actionPerformed(ActionEvent actione){
System.out.println("Statement action in the listener"); //This is where the action is!!!
}
}
<html>
<head><title>EventTest (EventTest.htm)</title></head>
<body>
Here is the EventTest:
<br clear="all">
<APPLET CODE="EventTest.class" WIDTH=450 HEIGHT=150>
</APPLET>
</body>
</html>


<a href="http://www.ajmasters.com" target="_blank" rel="nofollow">http://www.ajmasters.com</a> Real Estate, Tampa Florida
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
even sub-packages have to be imported...
importing java.awt.* does not import every sub-package of java.awt !


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
This is just my own personal opinion/gripe, but I find that using the wildcard import is a bad practice. I prefer to use the exact import, especially when I'm only using a few classes in a large package.
Take that for what it's worth.
Corey


SCJP Tipline, etc.
Rob Ross
Bartender

Joined: Jan 07, 2002
Posts: 2205
Ie.,package import statements do not recursively include sub-packages. You have to explicitly include each package as a seperate import statement.


Rob
SCJP 1.4
Mario Levesque
Ranch Hand

Joined: Nov 01, 2000
Posts: 51
Thanks for your quick reply Valentin,
This bring another question
How do you know if you have sub packages that will need to be imported? i.e. Is there a way to find out if a high level package import won't be sufficient?
Thanks
Mario
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
If you reference a class without using its fully qualified name, you'll have to import the package that class came from or you'll get a compiler error.
Don't think about high-level imports or low-level imports. As far as imports are concerned, all packages are created equal. Just because one package is name foo and another one is named foo.bar, they have nothing to do with one another when it comes to importing them.
If you use a class in package foo, you'll have to import package foo. If you use a class in foo.bar, you'll have to import package foo.bar. That's just the way it works.
I hope that helps,
Corey
Mario Levesque
Ranch Hand

Joined: Nov 01, 2000
Posts: 51
So, if I get this right..
The star as a suffix means include not only one but all classes and interfaces in the present package in the present directory and that's it.
No classes or interfaces from other packages in other subdirectories. Event if they start with the same package (directory) structure.
Thanks to all.
Mario
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Yup, that's right. When you say:

That tells the compiler that you want access to all classes and interfaces within the package foo. This says nothing about any other packages, such as baz or foo.bar.
Corey
Mario Levesque
Ranch Hand

Joined: Nov 01, 2000
Posts: 51
Is it ok to talk about the concept of package being in only one directory?
Or is the concept of package dis-associated with directories, kind of like a virtual grouping meaning that two seperate source files located in different directories can belong to the same package just by having the package declaration at the top?
If this is the case, I'm still a bit confused because I think that I read that the periods are used to represent the directory structure in whatever operating system the program is running!!
Rob Ross
Bartender

Joined: Jan 07, 2002
Posts: 2205
The key is that every compilation unit can belong to exactly ONE package, and the name of that package is specified in the package statement at the beginning of the file:
package foo.bar;
Now, if two compilation units have the same package declaration, you can say they are in the "same package."
When you are writing your source code, you don't have to keep these files in the same hard drive directory, although this is sort of like saying you don't have to use any Microsoft software. You could go to extreme measures to not do either, but in common practice you will.

When it comes to compilation and running your application though, it's a different story. The JVM and javac need to know explicitly how to find your classes, and more specifically, how to locate a particular package so it can find your classes there. If you don't have all your classes that are in foo.bar in the same directory, it's going to be a lot more work for you to create multiple class path references to the same package in different directories.
So I would say, unless you are doing something really advanced that requires you to introduce this kind of complexity, just "go with the flow" and assume you are always going to keep all the classes that belong to the same package together in the same physical hard-drive directory folder.
[ March 19, 2002: Message edited by: Rob Ross ]
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Indeed, packages and directories are related. Take the following example:

If I compile this and place it on my root C: directory, when I try to run it, I get the following compiler error:

However, if I put the file PackageTest.class into the directort C:\foo\bar\baz, the application executes fine.
That's how the package names and directory structure are related. The JVM looks through a directory structure (designated by the package name) to find the .class file that it needs. So, when you say that you want to run foo.bar.baz.PackageTest, the JVM looks into C:\foo\bar\baz to find the file PackageTest.class. If it's not there, it returns an error. Had I placed the file PackageTest.class into a subdirectory for baz, such as C:\foo\bar\baz\bop, I'd still get a compiler error because the JVM goes to the specific directoty C:\foo\bar\baz to find the class file. If it's not there, it doesn't recursively dig through subdirectories, it just gives up and issues an error. This same principle holds true for imports.
Therefore, if you were, in some file to say:

the compiler would catch this as an error. The reason for the comiler error is because it does the same check the JVM would do at run-time. It looks through the package hierarchy to see if the class PackageTest is in foo.bar. It finds that it's not, so it produces an error.
I hope this makes sense. The key to remember is that packages and directory structure are related, but importing a package does not recursively import any subpackages.
Hope that helps,
Corey
Mario Levesque
Ranch Hand

Joined: Nov 01, 2000
Posts: 51
Thanks Guys.
It makes a lot more sense now.
Mario
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
This is just my own personal opinion/gripe, but I find that using the wildcard import is a bad practice. I prefer to use the exact import, especially when I'm only using a few classes in a large package.
Fair enough but are you ready to write 60 import statements in the case you are using almost all classes of a given package?
There is no performance penalty when specifying a ".*" import instead of just the class you need.
I do admit that for small classes which do not use many classes, writing one import statement per used class may be better (for maintenance purposes and code readability) than a nice ".*" import. But again it's a matter of taste I guess.
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
I think my key point was that I prefer using specific imports especially when you're only using a few classes from a large package.
In the case that you're using 99 out of 100 classes in a package, I guess I'd have to recommend using a full package import.
To a great extent, I feel that this is a matter of personal preference, but I'll try to lay out a couple of functional examples that show the implications on your application of using package imports. I'm sure someone can find similar arguments against using specific imports, but here goes.
1. Using package imports can cause namespace pollution. The goal of using import statements is to remove fully qualified class names from our code. Take the following example:

On the first line, the compiler issues an error because it doesn't know which Dog class to use. Instead, you're forced to use the fully qualified name which is what we wanted to avoid in the first place. It would seem that you'd seldom run into such a problem but, when you're working on a large scale application that utilizes lots of packages, the chance of name-space collisions increases.
2. Using package imports can also be a maintenance headache. Imagine you're given an enterprise level Java application that you need to update. This application was written by someone that is no longer with your company and there is little documentation (believe me, this happens much more often that I'd like to admit). If there is a class being utilized named Foo, you'd have to look through every package imported (for large applications, there may be many) just to track down the class Foo so that you can see what it does.
So those are a couple points I'd like people to be aware of when they're going to use package imports. I just wanted to point out that whether to use a package import or a specific import isn't entirely a preferential decision. This can be a design decision, just like any other. Don't get me wrong, package imports are great when used appropriately but, as far as I'm concerned, you should never use import java.util.* when all you're going to use is ArrayList.
Corey
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Even if you import a specific class you may have to write its fully qualified name in your code to avoid ambiguities.
I take the same example:

I agree with you that it is cleaner to specifically import classes. But, import them all does not actually load them all.
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Indeed, you're right. I guess I should have clarified some more. What I was really getting at would be a case where you've imported two packages, both of which have a Dog class. However, if you only need to use one of the two Dog classes (you have absolutely no use for the other one), then you're causing namespace collisions when there don't need to be. For example, if you only needed pet.Dog and you only needed animal.Animal, you could avoid the namespace collision around the Dog class by performing specific imports.
Corey
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
That's perfectly right...
I didn't mean to nitpick... I just wanted to make things clear
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: java.awt.*; and java.awt.event.*
 
Similar Threads
Can I call System.exit() from an applet ? If so, how ?
Not able to run ActionListener
Paint() method... Easy Question
Applet -Applet communication prb
Sorry - Newbie question...