1- # ** 1. ENUM枚举**
2- ## ** 1.1 枚举概述**
1+ # JDK5新特性
2+
3+ ## ** 1. ENUM枚举**
4+
5+ ### ** 1.1 枚举概述**
36枚举是指将变量的值一一列出来,变量的值只限于列举出来的值的范围内。举例:一周只有7天,一年只有12个月等。
47
58回想单例设计模式:单例类是一个类只有一个实例
@@ -12,7 +15,7 @@ public enum 枚举类名 {
1215 枚举项1 ,枚举项2 ,枚举项3 …;
1316 }
1417```
15- ## ** 1.2 注意事项**
18+ ### ** 1.2 注意事项**
1619
1720- 定义枚举类要用关键字enum
1821- 所有枚举类都是Enum的子类
@@ -21,11 +24,11 @@ public enum 枚举类名 {
2124- 枚举类也可以有抽象方法,但是枚举项必须重写该方法
2225- 枚举在switch语句中的使用
2326
24- ## ** 1.3 枚举类中的几个常见方法**
27+ ### ** 1.3 枚举类中的几个常见方法**
2528
2629![ enum枚举] ( http://img.blog.csdn.net/20161019100055988 )
2730
28- ##** 1.4 枚举的应用**
31+ ### ** 1.4 枚举的应用**
2932
3033** 用法一:常量**
3134
@@ -170,11 +173,11 @@ public interface Food {
170173}
171174```
172175
173- ## 1.5 常量接口 vs 枚举常量类
176+ ### 1.5 常量接口 vs 枚举常量类
174177
175178把常量定义在接口里与类里都能通过编译,那2者到底有什么区别呢?那个更合理?
176179
177- ### 常量接口
180+ #### 常量接口
178181``` java
179182public interface ConstInterfaceA {
180183 public static final String CONST_A = " aa" ;
@@ -197,7 +200,7 @@ public interface ConstInterfaceA {
197200- 编译时,是直接把常量的值编译到类的二进制代码里,常量的值在升级中变化后,需要重新编译所有引用常量的类,因为里面存的是旧值.
198201
199202
200- ### 常量类
203+ #### 常量类
201204
202205``` java
203206public class ConstClassA {
@@ -213,7 +216,7 @@ public class ConstClassA {
213216但是其他问题与常量接口一样无法解决
214217
215218
216- ### 枚举常量类
219+ #### 枚举常量类
217220
218221``` java
219222public class EnumClassA {
@@ -263,7 +266,7 @@ public static enum Grade {
263266```
264267这是JDK1.5引入的,其实就是枚举常量类的代码封装简化而已。查看enum反编译后的代码与枚举常量类的结构非常相似。这可能是因为java的设计者一开始觉得enum与OO思想不符,所以没有提供支持,但是随着常量接口的滥用和枚举常量类方案的出现,才在JDK1.5里增加了enum
265268
266- # ** 2. 静态导入**
269+ ## ** 2. 静态导入**
267270
2682711、要使用用静态成员(方法和变量)我们必须给出提供这个方法的类。使用静态导入可以使被导入类的所有静态变量和静态方法在当前类直接可见,使用这些静态成员无需再给出他们的类名。
269272
@@ -317,7 +320,7 @@ public class StaticImportDemo {
317320}
318321```
319322
320- # ** 3. 增强for循环**
323+ ## ** 3. 增强for循环**
321324
3223251、增强for:是for循环的一种。
3233262、格式:
@@ -405,7 +408,7 @@ public class ForDemo {
405408}
406409```
407410
408- # ** 4. 可变参数**
411+ ## ** 4. 可变参数**
409412
4104131、可变参数概述:定义方法的时候不知道该定义多少个参数
4114142、格式
@@ -529,7 +532,7 @@ public class ArraysDemo {
529532
530533![ 可变参数] ( http://img.blog.csdn.net/20150829015634395?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center )
531534
532- # ** 5. 基本数据类型的自动拆箱与装箱**
535+ ## ** 5. 基本数据类型的自动拆箱与装箱**
533536
5345371、自动装箱:把基本类型转换为包装类类型
5355382、自动拆箱:把包装类类型转换为基本类型
@@ -567,4 +570,209 @@ public class IntegerDemo {
567570 }
568571 }
569572}
570- ```
573+ ```
574+ ## 6. 编译时注解APT
575+
576+ # JDK8新特性
577+
578+ ## 泛型的类型推导
579+
580+ ### ** 1. 泛型究竟是什么?**
581+
582+ 在讨论类型推导(type inference)之前,必须回顾一下什么是泛型(Generic).泛型是Java SE 1.5的新特性,泛型的本质是参数化类型,也就是说所操作的数据类型被指定为一个参数。通俗点讲就是“类型的变量”。这种类型变量可以用在类、接口和方法的创建中。理解Java泛型最简单的方法是把它看成一种便捷语法,能节省你某些Java类型转换(casting)上的操作:
583+
584+ ``` java
585+ List<Apple > box = new ArrayList<Apple > ();box. add(new Apple ());
586+ Apple apple = box. get(0 );
587+ ```
588+
589+ 上面的代码自身已表达的很清楚:box是一个装有Apple对象的List。get方法返回一个Apple对象实例,这个过程不需要进行类型转换。没有泛型,上面的代码需要写成这样:
590+
591+ ``` java
592+ Apple apple = (Apple )box. get(0 );
593+ ```
594+
595+ 当然,泛型绝不像我在这里描述的这么简单,但这不是我们今天的主角,对于泛型还不是很明白的同学需要补课了~当然,最好的参考资料还是官方文档。
596+
597+ ### ** 2. 泛型带来的问题(Java 7之前)**
598+
599+ 泛型的最大优点是提供了程序的类型安全同时可以向后兼容,但也有让开发者不爽的地方,就是每次定义时都要写明泛型的类型,这样显式指定不仅感觉有些冗长,最主要是很多程序员不熟悉泛型,因此很多时候不能够给出正确的类型参数,现在通过编译器自动推断泛型的参数类型,能够减少这样的情况,并提高代码可读性。
600+
601+ ### ** 3. Java 7中对于泛型的类型推导方面的改进**
602+
603+ 在Java 7以前的版本中使用泛型类型,需要在声明并赋值的时候,两侧都加上泛型类型。比方说这样:
604+
605+ ``` java
606+ Map<String ,Integer > map = new HashMap<String ,Integer > ();
607+ ```
608+
609+ 很多人当初肯定和我一样,对此感到很不解:我在变量声明中不是已经声明了参数类型了吗?为什么在对象初始化的时候还要显示的写出来?这也是泛型在一开始出现的时候受到很多人吐槽的地方。不过,让人欣慰的是,java在进步的同时,那些设计者们也在不断的改进java的编译器,让它变的更加智能与人性化。这里,就是我们今天的主角:类型推倒...额...不是推倒,是类型推导,即type inference,这哥们儿的出现,再写上面这样的代码的时候,可以很开心地省略掉对象实例化时的参数类型,也就变成了这个样子:
610+
611+ ``` java
612+ Map<String ,Integer > map = new HashMap<> ();
613+ ```
614+
615+ 在这条语句中,编译器会根据变量声明时的泛型类型自动推断出实例化HashMap时的泛型类型。再次提醒一定要注意new HashMap后面的“< ; >”,只有加上这个“< ; >”才表示是自动类型推断,否则就是非泛型类型的HashMap,并且在使用编译器编译源代码时会给出一个警告提示(unchecked conversion warning)。这一对尖括号"< ; >"官方文档中叫做"diamond"。
616+
617+ 但是,这时候的类型推导做的并不完全(甚至算是一个半成品),因为在Java SE 7中创建泛型实例时的类型推断是有限制的:只有构造器的参数化类型在上下文中被显著的声明了,才可以使用类型推断,否则不行。例如:下面的例子在java 7无法正确编译(但现在在java8里面可以编译,因为根据方法参数来自动推断泛型的类型):
618+
619+ ``` java
620+ List<String > list = new ArrayList<> ();
621+ list. add(" A" );// 由于addAll期望获得Collection<? extends String>类型的参数,因此下面的语句无法通过
622+ list. addAll(new ArrayList<> ());
623+ ```
624+
625+ ### ** 4. 在Java8中的再进化**
626+
627+ - 支持通过方法上下文推断泛型目标类型
628+ - 支持在方法调用链路当中,泛型类型推断传递到最后一个方法
629+
630+ 在最新的java官方文档之中,我们可以看到对于类型推导的定义:
631+
632+ ```
633+ Type inference is a Java compiler's ability to look at each method invocation and corresponding declaration to determine the type argument (or arguments) that make the invocation applicable. The inference algorithm determines the types of the arguments and, if available, the type that the result is being assigned, or returned. Finally, the inference algorithm tries to find the most specific type that works with all of the arguments.
634+ ```
635+
636+ 简言之,类型推导也就是指编译器能够根据你调用的方法和相应的声明来确定需要的参数类型的能力。并且官方文档中还给出了一个例子加以诠释:
637+
638+ ``` java
639+ static < T > T pick(T a1, T a2) {
640+ return a2;
641+ }
642+ Serializable s = pick(" d" , new ArrayList<String > ());
643+ ```
644+
645+ 在这里,编译器能够推导出传入pick方法中的第二个参数的类型是Serializable的。
646+
647+ 在之前的java版本当中,上面的例子要能够通过编译的话需要这要写:
648+
649+ ``` java
650+ Serializable s = this . < Serializable > pick(" d" , new ArrayList<String > ());
651+ ```
652+
653+ 这样写的详细原因可以在Bruce Eckel的java编程思想(第四版)的泛型一章看得到,当然这本书是基于java6的,这个版本还没有类型推导这个概念。看到这里,很多人已经明显能看得出来最新版本中类型推导的强力之处了。已经不仅仅局限于泛型类的声明与实例化过程了,而是延伸到了具有泛型参数的方法当中了。
654+
655+ #### ** 4.1 类型推导和泛型方法**
656+
657+ Type Inference and Generic Methods
658+
659+ 关于新版本中的类型推导和泛型方法,文档中还给了一个稍微复杂一点的例子,我在这里贴出来,原理和上面的Serializable例子都是一样就不再赘述,想巩固的可以再看一下:
660+
661+ ``` java
662+ public class BoxDemo {
663+
664+ public static <U > void addBox (U u , java.util.List<Box<U > > boxes ) {
665+ Box<U > box = new Box<> ();
666+ box. set(u);
667+ boxes. add(box);
668+ }
669+
670+ public static <U > void outputBoxes (java.util.List<Box<U > > boxes ) {
671+ int counter = 0 ;
672+ for (Box<U > box: boxes) {
673+ U boxContents = box. get();
674+ System . out. println(" Box #" + counter + " contains [" +
675+ boxContents. toString() + " ]" );
676+ counter++ ;
677+ }
678+ }
679+
680+ public static void main (String [] args ) {
681+ java.util.ArrayList<Box<Integer > > listOfIntegerBoxes =
682+ new java.util.ArrayList<> ();
683+ BoxDemo . < Integer > addBox(Integer . valueOf(10 ), listOfIntegerBoxes);
684+ BoxDemo . addBox(Integer . valueOf(20 ), listOfIntegerBoxes);
685+ BoxDemo . addBox(Integer . valueOf(30 ), listOfIntegerBoxes);
686+ BoxDemo . outputBoxes(listOfIntegerBoxes);
687+ }
688+ }
689+ ```
690+
691+ 上面这段代码输出为:
692+
693+ ```
694+ Box #0 contains [10]
695+ Box #1 contains [20]
696+ Box #2 contains [30]
697+ ```
698+
699+ 提一下,泛型方法addBox重点就在于在新java版本中你不需要再在方法调用中进行显式的类型说明,像这样:
700+
701+ ```
702+ BoxDemo.<Integer>addBox(Integer.valueOf(10), listOfIntegerBoxes);
703+ ```
704+
705+ 编译器能够从传入addBox中的参数自动推断出参数类型是Integer.
706+
707+ #### ** 4.2 类型推导与泛型类和非泛型类的泛型构造器**
708+
709+ 额...这个也许英语的更好断句一点:Type Inference and Generic Constructors of Generic and Non-Generic Classes
710+
711+ 其实,泛型构造器并不是泛型类的专利品,非泛型类也完全可以有自己的泛型构造器,看一下这个例子:
712+
713+ ``` java
714+ class MyClass <X> {
715+ <T > MyClass (T t ) {
716+ // ...
717+ }
718+ }
719+ ```
720+
721+ 假如对 MyClass类做出下面这样的实例化:
722+
723+ ``` java
724+ new MyClass<Integer > (" " )
725+ ```
726+
727+ OK,这里我们显示地指出了MyClass的泛参类型X是Integer,而对于构造器,编译器根据传入的String对象("")推导出形式参数T是String,这个在java7版本之中已经实现了,在Java8中有了什么改进呢?在Java8之后,对于这种具有泛型构造器的泛型类的实例化我们可以这么写:
728+
729+ ``` java
730+ MyClass<Integer > myObject = new MyClass<> (" " );
731+ ```
732+
733+ 对,还是这一对尖括号(< ; >),江湖人称diamond,这样我们的编译器就能够自动推导出形式参数X是Integer,T是String了。这个其实和我们一开始Map< ; String,String>的例子很像,只是多了个构造器的泛型化。
734+
735+ 需要注意的是:类型推导只能根据调用的参数类型、目标类型(这个马上会讲到)和返回类型(如果有返回的话)进行推导,而不能根据程序后面的一些需求来进行推导。
736+
737+ #### ** 4.3 目标类型(Target Type)**
738+
739+ 前文已经提到过,编译器能够根据目标类型进行类型推导。一个表达式的目标类型指的是一种编译器根据表达式出现的位置而需要的正确的数据类型。比如这个例子:
740+
741+ ``` java
742+ static < T > List<T > emptyList();
743+ List<String > listOne = Collections . emptyList();
744+ ```
745+
746+ 在这里,List< ; String>就是目标类型,因为这里需要的是List< ; String>,而Collections.emptyList()返回的是List< ; T>,所以这里编译器就推断T一定是String。这个在Java 7 和 8 中都OK。但是在java 7 中,在下面这种情况中就不能正常编译了:
747+
748+ ``` java
749+ void processStringList(List<String > stringList) {
750+ // process stringList
751+ }
752+
753+ processStringList(Collections . emptyList());
754+ ```
755+
756+ 这个时候,java7就会给出这种错误提示:
757+
758+ ``` java
759+ // List<Object> cannot be converted to List<String>
760+ ```
761+
762+ 原因:Collections.emptyList() 返回的是List< ; T> ,这里的T需要一个具体类型,但是因为不能从方法声明中推断出所需的是String,所以编译器就给T了一个Object的值,很明显,List< ; Object>不能转型到List< ; String>.所以在java7版本中你需要这样调用这个方法:
763+
764+ ``` java
765+ processStringList(Collections . < String > emptyList());
766+ ```
767+
768+ 但是,在java8中,由于目标类型概念的引入,这里,很明显编译器需要的是List< ; String>(也就是这里的Target Type),所以编译器推断返回的List< ; T>中的T一定是String,所以processStringList(Collections.emptyList());这种描述是OK的。
769+
770+ 目标类型的使用在Lambda表达式中优势最为明显,相关内容我会慢慢整理出来。
771+
772+ 好了,以上就是关于java中类型推导的一些跟人见解,总结来说,越来越完善的类型推导就是完成了一些本来就感觉很理所当然的类型转换工作,只是这些工作满满地全交给了编译器去自动推导而不是让开发者显示地去指定。
773+
774+ ## ** Lambda表达式**
775+
776+ ## ** 接口的默认方法与静态方法**
777+
778+ ## ** 方法引用**
0 commit comments