Shulou(Shulou.com)06/01 Report--

This article mainly shows you "how to use the import keyword in Java". The content is simple and clear. I hope it can help you solve your doubts. Let me lead you to study and learn this article "how to use the import keyword in Java".

1. Package

Unlike java's # include, which adds what it contains to the program file at compile time, it is not the same for java.

Let's first take a look at the use of Java's package.

The package name is like our last name and the class name is like our first name. The adjunct relationship between package and package is "." To connect, it's like a compound surname. For example, java.lang.String is the category with the surname java.lang and the first name String, while java.io.InputStream is the category with the surname java.io and the first name InputStream.

The reason why Java will use the package mechanism is also very obvious. Just like we take names, there may be many students with the same name in the same class of the same school. If the school does not take the surname, then the school will have great trouble in dealing with student data or addressing students to each other. Similarly, there are probably more Java classes in the world than the Japanese, and if the category does not use the package name, it will cause great trouble when using different classes with the same name. So the package approach greatly reduces naming conflicts between classes.

We can choose the package name of Java ourselves, unlike there is not much choice for people's last name (so there are many cases of the same surname), if we choose the suite name according to the Sun specification, then theoretically different people will not choose the same suite name (please refer to the relevant article of "naming convention" if necessary), and there will be no name conflict.

But now the problem is, because many package names are very long, when programming, you have to use multiple package names for one class. The class name is fully written, which makes the code lengthy and reduces simplicity. For example

Java.io.InputStream is = java.lang.System.in;java.io.InputStreamReader isr= new java.io.InputStreamReader (is); java.io.BufferedReader br = new java.io.BufferedReader (isr)

It was very troublesome, so Sun introduced import.

II. Import

Import is at the beginning of the java file, explaining which categories will be used first.

Then we can specify a class in the code with only the class name, that is, only the first name, not his last name.

First, write at the beginning of the program:

Import java.lang.System;import java.io.InputStream;import java.io.InputStreamReader;import java.io.BufferedReader

So we can write in the program like this:

InputStream = System.in;InputStreamReader isr = new InputStreamReader (is); BufferedReader br = new BufferedReader (isr)

A java file is like a large room. We write the last name and first name of the class in the room at the door, so we can just use his first name to mention a class in the room. For example:

System means java.lang.System, and InputStream means java.io.InputStream.

But if there are more than one "last name" in a java file, that is, classes with the same package name (for example, the InputStream,InputStreamReader,BufferedReader above are all classes in java.io), it is cumbersome for us to write them one by one, so Sun allows us to use

Import java.lang.*;import java.io.*

Indicates that the classes mentioned in the file are either java.lang packages or java.io packages. The compiler will help us select the package that corresponds to the class name.

Can we be a little more lazy and write the following statement directly?

Import java.*

History tells us that this will not work. Because those categories are surnamed java.io rather than java. Just like a person surnamed "Zhuge" won't like it when you call him Mr. Zhu. If written in this way, only the classes under the java package will be declared, not any classes of the subpackages.

Note here that the classes in the java.lang package are so commonly used that there are almost no classes that don't use it, so whether you write import java.lang or not, the compiler will automatically fill it up for you, that is to say, as long as the compiler sees a category without a last name, it will automatically look for it in the lang package. So we don't have to go to import java.lang specially.

At first, import is different from # include because import doesn't load the contents of other java files like # include. Import simply asks the compiler to compile the java file by adding the last name to the category that does not have a last name, and does not write in other file programs. You don't have to use import if you're happy, just call it by its full name when you use a category (as you did at the beginning of the example), which is exactly the same as using import.

III. Two import declarations of import

Single type import (single-type-import) (example: import java.util.ArrayList;)

On-demand type import (type-import-on-demand) (example: import java.util.*;)

Have the following attributes:

Java imports classes and interfaces of any public in the package in two ways (only public classes and interfaces can be imported)

As mentioned above, import declarations import only classes under the declaration directory, not subpackages, which is why they are called type import declarations.

The simplified name (simple name) of the imported class or interface has the scope of the compilation unit. This means that the type short name can be used anywhere in the compilation unit where the import statement is located. This does not mean that you can use the short names of all members of the type, but only the short names of the type itself. For example, public classes in the java.lang package are automatically imported, including Math and System classes. However, you cannot use the initials PI () and gc () of their members. Instead, you must use Math.PI () and System.gc (). What you don't need to type are java.lang.Math.PI () and java.lang.System.gc ().

Programmers sometimes import the current package or java.lang package, which is not necessary because the members of the current package themselves are in scope, while the java.lang package is imported automatically. The java compiler ignores these redundant import declarations (redundant import declarations). Even if import java.util.ArrayList;import java.util.*; is imported multiple times like this, it can be compiled and passed. The compiler ignores the redundant import declaration.

IV. Static import of static import

In Java programs, it is not allowed to define independent functions and constants. That is, what property or method must be attached to something, such as using a class or interface as an attachment unit (various members can be attached to a class, while constants can only be attached to an interface).

If you want to not write out the attachment units of members of other classes or interfaces directly in the program, there is a workaround:

Define all the constants into an interface, and then let the classes that need these constants implement the interface (such an interface has a special name, called ("Constant Interface"). This method can work. However, because this makes it possible to infer "which constants the class needs to use" from "which interface a class implements", there is the problem of "exposing implementation details".

So the "Static Import" mechanism was introduced in J2SE 1.5, which allows static members to be used by omitting the name of the class or interface they are in. One of the inconsistencies between static import and import is that static import imports static members, while import imports classes or interface types.

The following is a class with static variables and static methods

Package com.assignment.test;public class staticFieldsClass {static int staticNoPublicField = 0; public static int staticField = 1; public static void staticFunction () {}}

Usually we use these static members with class names. Used in the form of static members, that is, staticFieldsClass.staticField or staticFieldsClass.staticFunction ().

Now use the static import way:

/ / * Precision Import * / / Import specific static variables, constants and methods directly. Note that the import method does not need parentheses to write the method name directly. Import static com.assignment.test.StaticFieldsClass.staticField;import static com.assignment.test.StaticFieldsClass.staticFunction;// or use the following form: / / * * Import on demand * * it is not necessary to indicate how static member names are imported one by one / / import static com.assignment.test.StaticFieldsClass.* Public class StaticTest {public static void main (String [] args) {/ / static members are written directly here without calling System.out.println (staticField) through the class name; staticFunction ();}}

Here are a few questions that need to be clarified:

Static Import does not have the right to change constraints that cannot use static members that cannot be used in the first place. The StaticTest and staticFieldsClass in the above example are not in the same package, so StaticTest can only access the variables of public in staticFieldsClass. The same is true with Static Import.

The imported static member conflicts with the same name of the local static member, in which case the processing rule is "local first."

Different classes (interfaces) can include static members with the same name. For example, during Static Import, there is a situation where "two import statements import static members with the same name". At times like this, J2SE 1.5 will deal with it like this:

If both statements are in the form of precise imports, or both are imported on demand, it will result in a compilation error.

If one statement is in the form of precise import and the other is in the form of on-demand import, then one in the form of precise import is valid.

I won't write examples of the above features as everyone is so smart.

Does static import have any negative effects on it like this?

The answer is yes, removing the type name in front of the static member helps to be concise when called frequently, but it also loses the prompt about "where is this thing defined?" and you can understand or maintain the code.

But if the source of the import is well known (such as java.lang.Math), the problem is less serious.

V. on-demand import mechanism

Does the use of on-demand import declarations reduce the execution efficiency of Java code?

* absolutely not! * *

Import 1.import on demand import java.util.*;public class NeedImportTest {public static void main (String [] args) {ArrayList tList = new ArrayList ();}}

The compiled class file:

/ / import java.util.* is replaced with import java.util.ArrayList//, that is, the on-demand import compilation process is replaced with a single-type import. On-demand import of import java.util.ArrayList;public class NeedImportTest {public static void main (String [] args) {new ArrayList ();}} 2.static import into import static com.assignment.test.StaticFieldsClass.*;public class StaticNeedImportTest {public static void main (String [] args) {System.out.println (staticField); staticFunction ();}}

After the above StaticNeedImportTest class is compiled:

/ / it can be seen that: / / 1, precise import of static import and on-demand import will become a single type of import after compilation, import import com.assignment.test.StaticFieldsClass;public class StaticNeedImportTest {public static void main (String [] args) {/ / 2, "hit back to the original" after compilation, and call the static member System.out.println (StaticFieldsClass.staticField) using the original method; StaticFieldsClass.staticFunction ();}} VI.

Does this mean that you can always use on-demand import declarations?

* * Yes and no! * *

It is useful to use on-demand import declarations in informal development like Demo.

However, there are four reasons why you can abandon this declaration:

Compilation speed: in a large project, they can greatly affect the compilation speed. However, the compilation time for use in small projects is negligible.

Naming conflicts: the answer to avoiding naming conflicts is to use full names. On-demand import is precisely the negation of the original intention of using the import declaration.

Explanation: after all, the code of the high-level language is for people to see, and you can't see the specific types used by import on demand.

Unnamed package problem: if there is no package declaration at the top of the compilation unit, the Java compiler first searches for a type from the unnamed package, followed by an on-demand type declaration. If there is a naming conflict, there will be problems.

Sun engineers generally do not use on-demand type import declarations. You can find this in their code:

Import declaration in the java.util.Properties class:

Import java.io.IOException;import java.io.PrintStream;import java.io.PrintWriter;import java.io.InputStream;import java.io.OutputStream;import java.io.Reader;import java.io.Writer;import java.io.OutputStreamWriter;import java.io.BufferedWriter;import java.security.AccessController;import java.security.PrivilegedAction

You can see that they use single-type imports to list in detail the specific types in the required java.io package.

The above is all the content of the article "how to use the import keyword in Java". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.