java中自动导入的包是什么，java如何导入包
大家好，感谢邀请，今天来为大家分享一下java中自动导入的包是什么的问题，以及和java如何导入包的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！
Java程序中,import的作用是什么
导入支持类（可以是JDK基础类或者自己编写的类），可以供本类调用方法和属性。
java中import用法单类型导入(single-type-import)，例如import
java.io.File;按需类型导入(type-import-on-demand)，例如
import
java.io.*;关于这两种导入类型大家各有所爱，众说纷纭。这里分析一下这两种导入类型的大致工作原理供大家参考。单类型导入比较好理解，仅仅导入一个public类或者接口。而对于按需类型导入，有人误解为导入一个包下的所有类，其实不然，看名字就知道，他只会按需导入，也就是说它并非导入整个包，而仅仅导入当前类需要使用的类。既然如此是不是就可以放心的使用按需类型导入呢？非也，非也。因为单类型导入和按需类型导入对类文件的定位算法是不一样的。java编译器会从启动目录(bootstrap)，扩展目录(extension)和用户类路径下去定位需要导入的类，而这些目录进仅仅是给出了类的顶层目录。编译器的类文件定位方法大致可以理解为如下公式：顶层路径名
\
包名
\
文件名.class
=
绝对路径对于单类型导入很简单，因为包明和文件名都已经确定，所以可以一次性查找定位。对于按需类型导入则比较复杂，编译器会把包名和文件名进行排列组合，然后对所有的可能性进行类文件查找定位。例如：package
com;import
java.io.*;import
java.util.*;当你的类文件中用到了File类，那么可能出现File类的地方如下File
\\
File类属于无名包，就是说File类没有package语句，编译器会首先搜索无名包com.File
\\
File类属于当前包java.lang.File
\\编译器会自动导入java.lang包java.io.Filejava.util.File需要注意的地方就是，编译器找到java.io.File类之后并不会停止下一步的寻找，而要把所有的可能性都查找完以确定是否有类导入冲突。假设此时的顶层路径有三个，那么编译器就会进行3*5=15次查找。了解以上原理之后，我们可以得出这样的结论：按需类型导入是绝对不会降低Java代码的执行效率的，但会影响到Java代码的编译速度。查看JDK的源代码就知道SUN的软件工程师一般不会使用按需类型导入。因为使用单类型导入至少有以下两点好处：1。提高编译速度。2。避免命名冲突。（例如：当你import
java.awt.*;import
java.util.*后，使用List的时候编译器将会出编译错误）当然，使用单类型导入会使用你的import语句看起来很长。
java如何导入包
1、首先在项目下创建一个新的文件夹，用来保存jar包。在项目名上点击鼠标右键，按顺序点击【New】→【Floder】，打开新建文件夹的窗口
2、输入文件夹名称【lib】，点击【ok】。通常在lib文件夹中存放从外部引入的jar包
3、找到要引入的jar包，鼠标选中需要用的jar包，然后按住鼠标左键不放，把jar包拖动到lib文件夹中。又或者是先复制jar包，接着在lib文件夹上右击，选择复制。打开选择框，在弹出的选择框中选择默认的【copy files】，点击【OK】关闭。接着就可以在lib文件夹下看到复制成功的jar包。
4、这时，只是把jar包复制到项目中，还不能够使用。需要再在项目名上点击鼠标右键，按顺序选择
【Build Path】→【Configure Build Path...】。
5、在打开的窗口中，选中【Libraries】页，从右边一栏的按钮中点击【add JARs...】
6、在打开的窗口中，按照顺序展开本项目和lib文件夹，然后选中刚刚复制到项目中的jar包，点击【OK】关闭窗口
7、在刚刚打开的【Libraries】页面中，可以看到刚刚引入的jar包名称。点击【OK】确认。
8、这个时候，在【Eclipse】中，就可以找到并且开始使用这个jar包了。
javaimport java.awt.*;什么意思
这个说的是导入
java.awt包下所有类型(更准确的说法),*代表指定包(java.awt)下"所有类型"
这个是使用指定包下的一个指定类型(或者所有类型)之前的类型声明.放在package语句之后
这里的类型不仅仅包括class类类型,还可能存在 interface接口类型,@interface(注解类型)
(主要看是什么包)
对于一个你从来没看到过的陌生的类型名有如下2点:
1).从import看导入的类型名:
,如果没有参考api或者其它资料,,是看不出它对应的是类,还是接口,还是注解;
因为:
import语句可以导入 class类类型,interface接口类型,@interface(注解类型),但是从类型名看不出对应具体的类型是类,还是接口,还是注解.
2).当然如果,从使用上看类型名:
如果是注解,在代码中使用注解,因为类型前有@做标记,一下子就看出它是注解类型,如果是类与接口,那就难分辨了.
另外补充解释:
1.有默认导入的包,即java.lang包.
例如:java.lang.System
经常使用的System类,虽然用了,但是没有发现它对应的import语句
原因是:
包下所有类型.也就是只要类型所在的包是java.lang就不需要import,已经默认隐式导入了,不导包可直接使用
如果要使用的类型所在的包是其它包,如java.io,java.lang,java.lang.reflect等的,都需要import语句:
(程序代码中用到class InputStream)importjava.io.InputStream;
导入才能使用包中的类型.
不过实际开发中,根据开发工具的提示,自己又很了解的,实际用到时根据提示导入那个包类型(如开发工具没有提示,又存在这样的包类型,这时才手动书写import语句)
2.注意:
import语句不是强制使用的,可以不用(早期做法),但推荐使用.
如果不用import语句,只是要用其中的一个类型,不用import语句,但是类型名必须使用全限定类型名,
即要指定它所在的包,
例如:如果要使用InputStream,不写import语句,
直接在代码中指定类型名为 java.io.InputStream,
这是早期的做法,但问题是每次用到某个类型都要指定包路径,如果包路径很长(开发包,一般类型路径很长的)
比如spring-web-4.2.x......jar包
下的HandlerMethodInvoker类型,所在的包是org.springframework.web.bind.annotation.support
如果不用import语句,在代码中直接写就是
org.springframework.web.bind.annotation.support.HandlerMethodInvoker
一个类型就占了差不多半行的可见空间,显然这样的代码的可读性变差.
所以java的开发者后来想到用利用"import包路径.类型名;"来解决这个问题.
使用import语句已经是业界默认的,所以大胆使用吧...
请回答把类放在包中有什么作用
别的地方抄的，不过很详细。
“进行面向对象的设计时，一项基本的考虑是：如何将发生变化的东西与保持不变的东西分隔开。”
这一点对于库来说是特别重要的。那个库的用户（客户程序员）必须能依赖自己使用的那一部分，并知道一旦新版本的库出台，自己不需要改写代码。而与此相反，库的创建者必须能自由地进行修改与改进，同时保证客户程序员代码不会受到那些变动的影响。
为达到这个目的，需遵守一定的约定或规则。例如，库程序员在修改库内的一个类时，必须保证不删除已有的方法，因为那样做会造成客户程序员代码出现断点。然而，相反的情况却是令人痛苦的。对于一个数据成员，库的创建者怎样才能知道哪些数据成员已受到客户程序员的访问呢？若方法属于某个类唯一的一部分，而且并不一定由客户程序员直接使用，那么这种痛苦的情况同样是真实的。如果库的创建者想删除一种旧有的实施方案，并置入新代码，此时又该怎么办呢？对那些成员进行的任何改动都可能中断客户程序员的代码。所以库创建者处在一个尴尬的境地，似乎根本动弹不得。
为解决这个问题，Java推出了“访问指示符”的概念，允许库创建者声明哪些东西是客户程序员可以使用的，哪些是不可使用的。这种访问控制的级别在“最大访问”和“最小访问”的范围之间，分别包括：public，“友好的”（无关键字），protected以及private。根据前一段的描述，大家或许已总结出作为一名库设计者，应将所有东西都尽可能保持为“private”（私有），并只展示出那些想让客户程序员使用的方法。这种思路是完全正确的，尽管它有点儿违背那些用其他语言（特别是C）编程的人的直觉，那些人习惯于在没有任何限制的情况下访问所有东西。到这一章结束时，大家应该可以深刻体会到Java访问控制的价值。
然而，组件库以及控制谁能访问那个库的组件的概念现在仍不是完整的。仍存在这样一个问题：如何将组件绑定到单独一个统一的库单元里。这是通过Java的package（打包）关键字来实现的，而且访问指示符要受到类在相同的包还是在不同的包里的影响。所以在本章的开头，大家首先要学习库组件如何置入包里。这样才能理解访问指示符的完整含义。
5.1包：库单元
我们用import关键字导入一个完整的库时，就会获得“包”（Package）。例如：
import java.util.*;
它的作用是导入完整的实用工具（Utility）库，该库属于标准Java开发工具包的一部分。由于Vector位于java.util里，所以现在要么指定完整名称“java.util.Vector”（可省略import语句），要么简单地指定一个“Vector”（因为import是默认的）。
若想导入单独一个类，可在import语句里指定那个类的名字：
import java.util.Vector;
现在，我们可以自由地使用Vector。然而，java.util中的其他任何类仍是不可使用的。
之所以要进行这样的导入，是为了提供一种特殊的机制，以便管理“命名空间”（Name Space）。我们所有类成员的名字相互间都会隔离起来。位于类A内的一个方法f()不会与位于类B内的、拥有相同“签名”（自变量列表）的f()发生冲突。但类名会不会冲突呢？假设创建一个stack类，将它安装到已有一个stack类（由其他人编写）的机器上，这时会出现什么情况呢？对于因特网中的Java应用，这种情况会在用户毫不知晓的时候发生，因为类会在运行一个Java程序的时候自动下载。
正是由于存在名字潜在的冲突，所以特别有必要对Java中的命名空间进行完整的控制，而且需要创建一个完全独一无二的名字，无论因特网存在什么样的限制。
迄今为止，本书的大多数例子都仅存在于单个文件中，而且设计成局部（本地）使用，没有同包名发生冲突（在这种情况下，类名置于“默认包”内）。这是一种有效的做法，而且考虑到问题的简化，本书剩下的部分也将尽可能地采用它。然而，若计划创建一个“对因特网友好”或者说“适合在因特网使用”的程序，必须考虑如何防止类名的重复。
为Java创建一个源码文件的时候，它通常叫作一个“编辑单元”（有时也叫作“翻译单元”）。每个编译单元都必须有一个以.java结尾的名字。而且在编译单元的内部，可以有一个公共（public）类，它必须拥有与文件相同的名字（包括大小写形式，但排除.java文件扩展名）。如果不这样做，编译器就会报告出错。每个编译单元内都只能有一个public类（同样地，否则编译器会报告出错）。那个编译单元剩下的类（如果有的话）可在那个包外面的世界面前隐藏起来，因为它们并非“公共”的（非public），而且它们由用于主public类的“支撑”类组成。
编译一个.java文件时，我们会获得一个名字完全相同的输出文件；但对于.java文件中的每个类，它们都有一个.class扩展名。因此，我们最终从少量的.java文件里有可能获得数量众多的.class文件。如以前用一种汇编语言写过程序，那么可能已习惯编译器先分割出一种过渡形式（通常是一个.obj文件），再用一个链接器将其与其他东西封装到一起（生成一个可执行文件），或者与一个库封装到一起（生成一个库）。但那并不是Java的工作方式。一个有效的程序就是一系列.class文件，它们可以封装和压缩到一个JAR文件里（使用Java 1.1提供的jar工具）。Java解释器负责对这些文件的寻找、装载和解释（注释①）。
①：Java并没有强制一定要使用解释器。一些固有代码的Java编译器可生成单独的可执行文件。
“库”也由一系列类文件构成。每个文件都有一个public类（并没强迫使用一个public类，但这种情况最很典型的），所以每个文件都有一个组件。如果想将所有这些组件（它们在各自独立的.java和.class文件里）都归纳到一起，那么package关键字就可以发挥作用）。
若在一个文件的开头使用下述代码：
package mypackage;
那么package语句必须作为文件的第一个非注释语句出现。该语句的作用是指出这个编译单元属于名为mypackage的一个库的一部分。或者换句话说，它表明这个编译单元内的public类名位于mypackage这个名字的下面。如果其他人想使用这个名字，要么指出完整的名字，要么与mypackage联合使用import关键字（使用前面给出的选项）。注意根据Java包（封装）的约定，名字内的所有字母都应小写，甚至那些中间单词亦要如此。
例如，假定文件名是MyClass.java。它意味着在那个文件有一个、而且只能有一个public类。而且那个类的名字必须是MyClass（包括大小写形式）：
package mypackage;
public class MyClass{
//...
现在，如果有人想使用MyClass，或者想使用mypackage内的其他任何public类，他们必须用import关键字激活mypackage内的名字，使它们能够使用。另一个办法则是指定完整的名称：
mypackage.MyClass m= new mypackage.MyClass();
import关键字则可将其变得简洁得多：
import mypackage.*;
//...
MyClass m= new MyClass();
作为一名库设计者，一定要记住package和import关键字允许我们做的事情就是分割单个全局命名空间，保证我们不会遇到名字的冲突——无论有多少人使用因特网，也无论多少人用Java编写自己的类。
5.1.1创建独一无二的包名
大家或许已注意到这样一个事实：由于一个包永远不会真的“封装”到单独一个文件里面，它可由多个.class文件构成，所以局面可能稍微有些混乱。为避免这个问题，最合理的一种做法就是将某个特定包使用的所有.class文件都置入单个目录里。也就是说，我们要利用操作系统的分级文件结构避免出现混乱局面。这正是Java所采取的方法。
它同时也解决了另两个问题：创建独一无二的包名以及找出那些可能深藏于目录结构某处的类。正如我们在第2章讲述的那样，为达到这个目的，需要将.class文件的位置路径编码到package的名字里。但根据约定，编译器强迫package名的第一部分是类创建者的因特网域名。由于因特网域名肯定是独一无二的（由InterNIC保证——注释②，它控制着域名的分配），所以假如按这一约定行事，package的名称就肯定不会重复，所以永远不会遇到名称冲突的问题。换句话说，除非将自己的域名转让给其他人，而且对方也按照相同的路径名编写Java代码，否则名字的冲突是永远不会出现的。当然，如果你没有自己的域名，那么必须创造一个非常生僻的包名（例如自己的英文姓名），以便尽最大可能创建一个独一无二的包名。如决定发行自己的Java代码，那么强烈推荐去申请自己的域名，它所需的费用是非常低廉的。
②：ftp://ftp.internic.net
这个技巧的另一部分是将package名解析成自己机器上的一个目录。这样一来，Java程序运行并需要装载.class文件的时候（这是动态进行的，在程序需要创建属于那个类的一个对象，或者首次访问那个类的一个static成员时），它就可以找到.class文件驻留的那个目录。
Java解释器的工作程序如下：首先，它找到环境变量CLASSPATH（将Java或者具有Java解释能力的工具——如浏览器——安装到机器中时，通过操作系统进行设定）。CLASSPATH包含了一个或多个目录，它们作为一种特殊的“根”使用，从这里展开对.class文件的搜索。从那个根开始，解释器会寻找包名，并将每个点号（句点）替换成一个斜杠，从而生成从CLASSPATH根开始的一个路径名（所以package foo.bar.baz会变成foo\bar\baz或者foo/bar/baz；具体是正斜杠还是反斜杠由操作系统决定）。随后将它们连接到一起，成为CLASSPATH内的各个条目（入口）。以后搜索.class文件时，就可从这些地方开始查找与准备创建的类名对应的名字。此外，它也会搜索一些标准目录——这些目录与Java解释器驻留的地方有关。
为进一步理解这个问题，下面以我自己的域名为例，它是bruceeckel.com。将其反转过来后，com.bruceeckel就为我的类创建了独一无二的全局名称（com，edu，org，net等扩展名以前在Java包中都是大写的，但自Java 1.2以来，这种情况已发生了变化。现在整个包名都是小写的）。由于决定创建一个名为util的库，我可以进一步地分割它，所以最后得到的包名如下：
package com.bruceeckel.util;
关于java中自动导入的包是什么到此分享完毕，希望能帮助到您。