Java8之后的那些新特性（一）局部变量var

　　本周开始，我将开启一个新的系列，这个系列是关于Java的。
　　在IDEA中2021年的一个调查中，程序员中使用Java的版本中，Java8仍是主流。新的长期支持版Java11，Java17并未有Java8流行。
　　我并不认为一定得使用新版的Java，但我们也要意识到Java8是在2014年发布的，距今已经是8年之久了。而在这8年中，类似Kotlin，Swift，TypeScript语言都在不断的更新优化自己的语言特性。
　　这使得Java8相比起来，在让代码更简洁优雅上越来越有所差距。好在，Java并未停止它前进的步伐，从Java8之后的许多个版本，在借鉴参考其它语言优秀的特性的基础之上，Java发展出了新的能让代码更简洁的语法特性。
　　一起来随我一起了解一下，究竟有哪些新的语言特性值得我们关注吧。
　　这是第一篇，我来说一下局部变量var这个特性吧。变量与常量
　　在声明变量这个事情上，大家所熟知的Java变量申明方式是：变量EntityRepositoryentityRepositorynewEntityRepositoryJPA（）；常量finalStringhttpMethodpost
　　Java变量申明的方式是类名称的方式来进行申明，如果是常量，则以final关键字来申明。
　　我们可以对比下其它语言的变量申明方式
　　Kotlin中是以var声明变量，val申明常量变量varentityRepositoryEntityRepositoryJPA（）常量valhttpMehodpost
　　TypeScript是以let来声明变量，const来申明常量变量letentityRepositorynewEntityRepositoryJPA（）常量consthttpMethodpost
　　Swift中是由var定义变量，let来定义常量变量varentityRepositoryEntityRepositoryJPA（）常量lethttpMethodpost
　　从上面对比可以看出，相较于Java的类型名称的定义方式，新的语言都偏好关键字名称的模式。类型自动判定
　　事实上，现代编程语言，都非常喜欢最大限度的使用类型自动判定，也就是关键字名称这种模式。
　　类型推定的基本原则是：只要通过上下文能猜测到的，就不需要明确声明它的类型
　　因为，一个显而易见的点是，这样的代码确实更简洁。
　　我们如果用关键字名称的写法来重写上述Java代码中的变量与常量定义，那我们的代码就是是如此：使用（关键字名称）的模式重写变量varentityRepositorynewEntityRepositoryJPA（）；常量varhttpMethodpost
　　依据类型自动判定的逻辑，编译器和我们程序员，都会很显而易见的猜测到，entityRepository的类型是EntityRepositoryJPA类的实例，而httpMethod则是一个String类型。
　　当然，上面这个例子可能不太令人感觉到必要性，因为简洁不到哪去，但在一些复杂的场景中，确实能简洁很多使用旧有模式CollectorString，？，MapString，LongbyOccurrencegroupingBy（Function。identity（），counting（））；使用var来重写varbyOccurrencegroupingBy（Function。identity（），counting（））；语法解析
　　所以，Java10引进了局部变量var这个关键字，最显著的一个原因就是：简化代码
　　很难说这个特性没有借鉴其它现代主流语言，我认为肯定是参考与借鉴了的。
　　但受限于Java过于长久的历史，这个特性相比其它语言，也只是个半吊子的实现，它有挺多的限制var关键字只能在方法中使用，不能在方法参数，类参数等上使用var是变量的含义，没有简化常量的关键字
　　其中，最大的一个受限就是，你只能在方法中的局部变量中使用var这个关键字TestvoidtestEntityExists（）｛varexistsrepository。exists（User。class，1L）；Assertions。assertFalse（exists）；varcreatedrepository。save（randomUser（））；existsrepository。exists（User。class，created。getId（））；Assertions。assertTrue（exists）；｝
　　如上代码所示，你只能在方法内部使用var，不能在其它地方使用这个关键字，而且它表示变量，对于常量，并无相应的关键字来简化。缺点与影响
　　优点我就不说了，上面说了，最大的也基本上是最主要的优点是让代码更简洁。
　　还是来说缺点吧。
　　就我个人的经历来说，我认为，对于长期使用Java语言的程序员来说，这个特性的缺点表现为如下：
　　Java程序员并不习惯这个风格
　　如果是前端，移动端的程序员，他们使用的主要编程语言都基本上是关键字名称的模式，会对这种风格非常熟悉。
　　比如对于我这样的，确实我在知道这个特性之后，非常喜欢这样，瞬间基本上就切换为这种模式了，因为我在其它语言中，都是这种风格，我习惯了关键字名字的风格。
　　但一直从事Java的程序员并不一样，类名名称的风格他们太熟悉了，对他们来说，这个半吊子特性并无特别使用的必要。
　　我们都非常喜欢自己熟悉的风格，不是么？
　　局部的优化而非全局性转变
　　Java的这个转变，并非是全局性的，你在类的变量，方法参数中，并不能使用这种风格。
　　这导致这个转变的影响面比较小，可能进一步加剧了大家对这个特性的忽略。
　　影响了代码的可读性
　　好吧，我们都知道，简洁性与可读性可能有时候方向不太一样；越简洁，有时候越难以阅读，啰嗦一点，可能读起来更容易理解。
　　这种风格，对于习惯了的人来说，并不存在阅读性上的减弱的影响，但对于Java程序员来说，感觉可读性还是会降低一些。
　　关于这一点，IDEA这个工具为了强化可读性，提供了一个非常有意思的工具辅助。参照下面的图
　　看到没，IDEA自动把var的类型显示出来了。
　　为什么IDEA要这么干？肯定是因为Java程序员不太熟悉这种风格，用这种方式来帮助和提醒程序员。
　　但站在经常使用其它语言的人，比如我这样的来看，这种并无太多必要。事实上，在IDEA中使用Kotlin时，压根就没有这种提示。
　　参照如图所示：
　　可见，这个提示是特意为Java准备的，非常贴心。值得赞赏的进步
　　在我知道Java有局部变量以后，受到我过往使用其它语言的影响，我确实很快转变过来了，这种转变几乎不费什么成本。而且从我的编码感觉上来看，这种确实令代码更简洁，这是肯定的。
　　但对于那些从始至终使用Java的程序员来说，这种转变我认为需要一些成本。
　　但为了追求代码的简洁性，这也是非常值得的。
　　当然，一切都由你自己随心所欲来决定了。
　　不过从这一点上来看，我倒是对Java这门语言刮目相看，它确实没有停止自己的步伐，不断的借鉴与学习其它现代语言的一些新的好的做法，改进自身。
　　而从Java8到现在最新的Java17，这个语言都升级了这么多个版本，改进的当然不会是只这一点。
　　仅凭我们对Java的热爱，我们也确实值得跟随我们喜欢的这门语言，不要再停留在八年前的版本了，不是么？
　　下一篇，我将继续聊聊Java8之后的有意思的新特性。、