Search...
FAQs Subscribe
Pie
FAQs
Recent topics Flagged topics Hot topics Best topics
Search...
Search within OCPJP Search Coderanch
Advance search Google search
Register / Login
thread boost granny polymorphism book review grid advertise on coderanch
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
thread boost book review grid advertise on coderanch building better world book meaningless drivel
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin
Bartenders:
  • Lou Hamers
  • Piet Souris
  • Frits Walraven

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

 
Mario Levesque
Ranch Hand
Posts: 51
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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
Author & Gold Digger
Posts: 7617
6
I like...
IntelliJ IDE Java
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
even sub-packages have to be imported...
importing java.awt.* does not import every sub-package of java.awt !

My Linked In

 
Corey McGlone
Ranch Hand
Posts: 3271
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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
Posts: 2205
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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
Posts: 51
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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

<a href="http://www.ajmasters.com" target="_blank" rel="nofollow">http://www.ajmasters.com</a>; Real Estate, Tampa Florida

 
Corey McGlone
Ranch Hand
Posts: 3271
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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

SCJP Tipline, etc.

 
Mario Levesque
Ranch Hand
Posts: 51
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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

<a href="http://www.ajmasters.com" target="_blank" rel="nofollow">http://www.ajmasters.com</a>; Real Estate, Tampa Florida

 
Corey McGlone
Ranch Hand
Posts: 3271
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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

SCJP Tipline, etc.

 
Mario Levesque
Ranch Hand
Posts: 51
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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!!

<a href="http://www.ajmasters.com" target="_blank" rel="nofollow">http://www.ajmasters.com</a>; Real Estate, Tampa Florida

 
Rob Ross
Bartender
Posts: 2205
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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 ]

Rob
SCJP 1.4

 
Corey McGlone
Ranch Hand
Posts: 3271
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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

SCJP Tipline, etc.

 
Mario Levesque
Ranch Hand
Posts: 51
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
Thanks Guys.
It makes a lot more sense now.
Mario

<a href="http://www.ajmasters.com" target="_blank" rel="nofollow">http://www.ajmasters.com</a>; Real Estate, Tampa Florida

 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
I like...
IntelliJ IDE Java
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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.

My Linked In

 
Corey McGlone
Ranch Hand
Posts: 3271
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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

SCJP Tipline, etc.

 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
I like...
IntelliJ IDE Java
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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.

My Linked In

 
Corey McGlone
Ranch Hand
Posts: 3271
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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

SCJP Tipline, etc.

 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
I like...
IntelliJ IDE Java
posted 22 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
That's perfectly right...
I didn't mean to nitpick... I just wanted to make things clear

My Linked In

 
Let nothing stop you! Not even this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
reply
    Bookmark Topic Watch Topic
  • New Topic
Boost this thread!
Similar Threads
More...