Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Questions about "import" statements  RSS feed

 
David Clark
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is an example from a Java demo that I have:
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

It's my understanding that the asterisk means import everything.

So, "import javafx.*" means import all of the classes from javafx, correct?

So, the above example could be redone as:
import javafx.application.*;
import javafx.event.*;
import javafx.scene.*;
import javafx.stage.*;

or even:
import javafx.*, correct?

I suppose that "import javafx.*" would make the overall file size bigger, but how much bigger? I also suppose that if I used "import javafx.*" there would be unused classes, correct?

I did notice that Netbeans underlined one of the import statements & when I hovered the mouse over it, it told me that that class was unused.
 
Norm Radder
Ranch Foreman
Posts: 2240
28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
would make the overall file size bigger

No. import statements are just paths to the locations of class files.  They are an extension of the classpath.  They help the compiler locate class files.
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Clark wrote:
or even:
import javafx.*, correct?


No. Import statements are not recursive. This import only imports the classes in the javafx package only.

Henry
 
Mel Reams
Greenhorn
Posts: 13
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:No. Import statements are not recursive. This import only imports the classes in the javafx package only.


Well I learned something today I've been working in Java for ages and I just assumed import statements were recursive - I very rarely use high level imports because I like to import just the stuff I need, so I guess it never came up.
 
David Clark
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I'm a bit confused now!

Please elaborate on the word "recursive". According to my dictionary, recursive means:
relating to or involving a program or routine of which a part requires the application of the whole, so that its explicit interpretation requires in general many successive executions.

What would happen if I ran this demo with "import javafx.*? It sure would save a lot of typing! I found out that there are over 4,000 classes in Java. I certainly don't want to search javadocs to find out the function of each of the 4,000 classes.

What happens when the demo is compiled if I enter "import javafx.*"? You state that the import statement is just a path to the class. If I wanted to make an executable JAR file, wouldn't there need to be a copy of the classes needed to run the program outside of the IDE or my computer?
 
Norm Radder
Ranch Foreman
Posts: 2240
28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
need to be a copy of the classes needed to run the program outside of the IDE or my computer?

Yes.  Most of the classes that are in packages that start with names like java and javax are part of the java environment and don't need to be handled.  Any packages you write or that are from third parties must be located on the classpath for the JVM to find them.

Note: As far as I know, you do not have to use import statements.  The code can be written using the full package names for all the classes and no import statements and there will be no difference in the generated class files.
 
Knute Snortum
Sheriff
Posts: 4073
112
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please elaborate on the word "recursive".

In this context, it just means that

import javafx.*;

doesn't include all the subpackages, like

import javafx.application.*;
import javafx.fxml.*;


etc. But in general, I dislike the "*" syntax.  I would much rather see the actual imports used.  Some IDEs will help you with this.  For instance, in Eclipse you can press Ctrl-O and all the import statements will be organized for you.
 
Paul Clapham
Sheriff
Posts: 22482
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Clark wrote:You state that the import statement is just a path to the class. If I wanted to make an executable JAR file, wouldn't there need to be a copy of the classes needed to run the program outside of the IDE or my computer?


No, the classes needed to run the program just need to be in the executable JAR file's classpath somewhere. And all of the classes in the standard API are automatically in every classpath; the "java" and "javaw" commands take care of that. So no, your executable JAR file isn't going to contain a copy of the java.lang.String class, for example.
 
Julian West
Ranch Hand
Posts: 91
3
Chrome Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Import statements are just shortcuts to keep you from having to type the entire name each time you use the class' methods and properties.

The * wildcard doesn't import the entire subclass tree, only the methods and properties of the class you specify.

If you didn't have "import javafx.event.ActionEvent;", you would have to type "javafx.event.ActionEvent" every time rather than just "ActionEvent".  Refactor your code without imports to see.
 
David Clark
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I've learned something! All this time I thought that the import statement meant that a copy of the class is imported to the program. When one searches for a file, the "*" is a wildcard. In Java it serves a different purpose. Very interesting!

It doesn't change the fact that Java has over 4,000 classes.

Sure, I can experiment with demos in books, but if I want to create something from scratch, I'll need to know the function of each class. Unlike the good ol' days before OOP, when one just wrote code. That's my main question. Say, I want to create a GUI tic-tac-toe game. I don't know which classes to use. I would need to list the rules of the game & come up with code that uses those rules. I certainly don't want to read 4,000 javadocs to find out what each class does. So, what do I do?
 
Norm Radder
Ranch Foreman
Posts: 2240
28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, what do I do?

Start small and build a vocabulary of the classes.  That's what most of us have done. Very few of us know all the classes. Pick a few classes and read the API docs.

I want to create a GUI tic-tac-toe game. I don't know which classes to use.

Post your design requirements on a forum and some one will give you recommendations for classes that could help.

the good ol' days before OOP, when one just wrote code.

That can still be done.  I am a big fan of roll-your-own.  I often prefer to write my own code rather than use one of the Java SE classes.
There are special areas like networking and file I/O that require you to use the Java classes, but a lot of it can be done manually (if you have the time and don't mind debugging all the time)
 
David Clark
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, it's API docs not javadocs. No wonder I couldn't find what I was looking for when I googled "javadocs"!
 
Norm Radder
Ranch Foreman
Posts: 2240
28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The API docs link: http://docs.oracle.com/javase/8/docs/api/index.html
 
Henry Wong
author
Sheriff
Posts: 23283
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Clark wrote:
It doesn't change the fact that Java has over 4,000 classes.

Sure, I can experiment with demos in books, but if I want to create something from scratch, I'll need to know the function of each class. Unlike the good ol' days before OOP, when one just wrote code. That's my main question. Say, I want to create a GUI tic-tac-toe game. I don't know which classes to use. I would need to list the rules of the game & come up with code that uses those rules. I certainly don't want to read 4,000 javadocs to find out what each class does. So, what do I do?



Perhaps, there is a bit of nostalgia in play here. Having still need to code in C, although I have no issues in understanding the API (because I have been doing it for so long), I hardly consider it the "good ol' days". Most of the time, the features that you need are buried in a man page, with names like twalk() or memcmp(), or most often than not, it is not available, and you have to write it yourself.

Having an API, that is cross referenced, that is too large to easily learn, that does too much, and that arguably has more than one way to do stuff ... is a problem I wouldn't mind having when I am working in C...

Henry
 
Campbell Ritchie
Marshal
Posts: 55698
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Clark wrote:. . . I thought that the import statement meant that a copy of the class is imported to the program.
That is the #include directive in C which includes the other code in your app. In the case of import, the classes you are using already exist and the JVM can find them, so there is no need to copy the class; that is an improvement over #include.
. . . In Java it serves a different purpose. . . .
It still counts as a wildcard. Remember that you are using a different language, and you would expect things to mean something different. If you go to France and think “actuellement” means the same as the English “actually”, you will get all sorts of weird looks.
. . . Unlike the good ol' days before OOP, when one just wrote code.
OOP was introduced in 1967, so do you remember the good ol' days before OOP? OOP was introduced because the procedural programming which pre-dated it is was found wanting. If you have previously written procedural code, you may find it takes a lot of effort to start thinking OO. Procedural code is easy to write because it looks like secondary school algebra, but it may be less reliable than OO.
That's my main question. Say, I want to create a GUI tic-tac-toe game. . . . I would need to list the rules of the game & come up with code that uses those rules. . . . So, what do I do?
You decide whether you are likely to need to reuse existing classes at all. You find tutorials about Java┬« programming, or you find somebody who can teach you, or you buy a book. You can go through the 4000 existing classes to look for what you need, but you might only need keyboard input and output. For the noughts and crosses, you will probably not need any other ready‑made classes. You would however need to create your own classes. If you add a GUI to that, you would look for a GUIs tutorial, which will suggest which classes to use.
 
Knute Snortum
Sheriff
Posts: 4073
112
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David Clark wrote:So, it's API docs not javadocs. No wonder I couldn't find what I was looking for when I googled "javadocs"!

Any application can have javadocs.  It's too general a term.  You're looking for the documentation for the Java API.  Googling "java api" will bring up the link you want.

BTW, writing javadocs for your own code is a good habit to get into.  Start your comments before a method with /** and end with */.  You can read all about it here.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!