为了解决上面提到的部分缺点，Java 14 提供了可以将参数类型检查和绑定局部变量类型合并到一起的 instanceof 操作。
就像这样式儿的：
首先在 if 代码块对 animal 的类型和 Cat 进行匹配。先看 animal 变量是否为 Cat 类型的实例，如果是，强转为 Cat 类型，并赋值给 cat。
需要注意的是变量名 cat 并不是一个真正存在的变量，只是模式变量的一个声明而已。你可以理解为固定语法。
变量 cat 和 dog 只有当模式匹配表达式的结果为 true 时才生效和赋值。所以如果你一不小心把变量用在别的地方，直接会提醒你编译错误。
所以你对比一下上面两个版本的代码，肯定是 Java 14 版本的代码更简洁，也更易懂。减少了大量的类型转换，而且可读性大大提高。
回到 Spring
你看，本来是看 Spring 的，怎么突然写到了 JDK 的新特性了呢？
那必然是我埋下的伏笔啊。
我给你看一个东西：
https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
官方在去年的 SpringOne 大会上就宣布了：Spring 6.0 和 Spring Boot 3 这两大框架的 JDK 基线版本是 17。
也就是说：我们很有可能在 JDK 8 之后，下一个要拥抱的版本是 JDK 17。
而我，作为一个技术爱好者的角度来说：这是好事，得支持，大力支持。
但是，作为一个写着 CRUD 的 Java 从业者来说：想想升级之后各种兼容性问题就头疼，所以希望这个拥抱不要发生在我短暂的职业生涯中。去让那帮年轻力壮，刚刚入行的小伙子们去折腾吧。
而当我把视角局限在这篇文章的角度，电光火石之间，我又想到了一个给 Spring 贡献源码的“骚”操作。
历史代码中这么多用 instanceof 的地方，我只要在 6.0 分支里面，把这些地方都换成新特性的写法，那岂不是一个更简单的贡献源码的方式？
但是，在提交 issues 之前，一般流程都是要先去查询一下有没有类似的提交。
所以在干这事之前，我还是先冷静的查询了一下。
一查，我都笑了...
我都能想到，肯定其他人也能想到，果然有人已经捷足先登了。
比如这里：
https://github.com/spring-projects/spring-framework/issues?q=instanceof
简单来说就是：老哥，这样的小改进，就还是不要提 issue 了吧。你得整个大的啊，别只改一个类啊。
我觉得也是，你改你改一个模块也行呀，比如这位老哥，改了 Spring-beans 模块下的 8 个文件：
这样才是针对这类改动的正确姿势。
反正我把路指在这里了，你要是有兴趣，可以去看看 Spring 6.0 的代码是不是还有一些没有改的地方，你去试着提交一把。
这个话题又回到我最开始表达的第一个观点了：
给开源项目贡献源码其实不是一件特别困难的事情，不要老想着一次就提交一整个功能上去。一点点改进，都是好的。
提交的东西确实是和 Spring 框架关系不大，但是你至少能体验一下给开源项目做贡献的流程和感觉吧，而且越大的项目，流程约精细，肯定是能学到东西。
而这个过程中学到的东西，绝对比你提交一个 instanceof 改进大的多，所以你还能说这样的提交是没有什么营养的嘛？
比如我去年的一篇文章中，就提到了 Dubbo 在对响应报文进行解码的时候有一个没必要的重复操作，可以删除一行校验相关的代码。
我没有去提对应的 pr，但是我写在了文章中。
有个读者看到后，当天中午就去提交了，官方也很快入库了。
去年年底的时候 Dubbo 社区搞了一个回馈活动，就给他送了一个咖啡杯：
意外惊喜，一行代码，不仅可以学点知识，还可以免费得个咖啡杯，就问香不香。
升华一下
好了，回顾一下这篇文章。
我从 @Async 支持表达式作为引子，引到了 instanceof 的新特性，接着又引到了 Spring 6 会以 JDK 17 作为基线版本。
其实我写这篇文章的时候，脑海中一直在萦绕着一句话：大风起于青萍之末。
instanceof，是青萍之末。
大风就是 JDK 17 作为基线版本。
关于为什么要用 JDK 17 作为基线版本，其实这是风华正茂的 Java 的一次渡劫。渡劫是否成功，关系着我们每一个从业者。
在云原生的“喧哗”之下，走在前面的人已经感受到：大风已经吹起来了。
比如周志明博士在一次名为《云原生时代，Java 的危与机》中说了这样的一段话：
未来一段时间，是 Java 重要的转型窗口期，如果作为下一个 LTS 版的 Java 17，能够成功集 Amber、Portola、Valhalla、Loom 和 Panama 的新能力、新特性于一身，GraalVM 也能给予足够强力支持的话，那 Java 17 LTS 大概率会是一个里程碑式的版本，带领着整个 Java 生态从大规模服务端应用，向新的云原生时代软件系统转型。
可能成为比肩当年从面向嵌入式设备与浏览器 Web Applets 的 Java 1，到确立现代 Java 语言方向（Java SE/EE/ME 和 JavaCard）雏形的 Java 2 转型那样的里程碑。
但是，如果 Java 不能加速自己的发展步伐，那由强大生态所构建的护城河终究会消耗殆尽，被 Golang、Rust 这样的新生语言，以及 C、C++、C#、Python 等老对手蚕食掉很大一部分市场份额，以至被迫从“天下第一”编程语言的宝座中退位。
Java 的未来是继续向前，再攀高峰，还是由盛转衰，锋芒挫缩，你我拭目以待。
而我，还只是看到了青萍之末。
最后，文章首发于公众号[why技术]，欢迎关注，第一时间接收最新文章。
