Java 诞生二十余载，而各有千秋的新语言则层出不穷；平安壹钱包的丁雪丰 15 年前接触 Java，而他依然最喜爱 Java。那么为什么他对 Java 如此笃定呢？而在为数不少的框架中，为什么他又选中 Spring 框架？Spring 技术有哪些适用和不适用的场景？为了一探究竟，InfoQ 对丁雪丰先生进行了采访。
此外，丁雪丰先生还将作为演讲嘉宾出席中国首届 Spring Summit 技术峰会，并进行《有了 Spring Boot，内部框架还缺什么？》的主题分享。此次峰会由 Pivotal 和极客邦科技联合主办，会议分设 Spring 生态 10 余个技术主题，邀请了十余位中美专家，将从从企业上云、传统行业在数字经济时代机遇与挑战等宏观战略层面，以及微服务、DevOps、Reactive、CloudNative Java 等微观技术层面，来诠释如何完成企业数字化转型这道考题。Spring Summit 2017 官网已经上线，各位读者可以移步了解详情。
InfoQ： 您从事 Java 开发数年，您怎么评价这门语言？为什么 Java 会成为世界上使用者最多的语言？ 丁雪丰：我是在 2002 年机缘巧合下开始正式学习并使用 Java 的，在那之前我都在使用微软系的东西。当时做的 Java 应用很多还是 Applet，在页面上呈现出酷炫的效果，用 Servlet 和 JSP 做后端服务的还不多。开个玩笑，当时 Java 号称“write once, run anywhere”，我天真地相信了，后来才理解到这真的只是一个美好的愿望。不过这并不妨碍 Java 的成功，我本人也是一名坚定的 Java 用户（虽然我经常会去学习各种新语言，但主要工作语言一直是 Java），如果翻看这几年的 TIOBE 排行榜，你就会发现它长期位居榜首，这就是大家对 Java 的认可。
一门语言好不好是仁者见仁智者见智的事。不过如果一门语言缺乏活力，那要么就是小众无人问津，要么就是开发者也放弃维护了。Java 有着庞大的社区和使用者，虽然出于商业等原因，步伐显得不如一些新兴语言这么快，但一直在稳步向前发展，同时还在不断借鉴其他人的经验，所以有理由相信，Java 在未来的一段时间里仍然会处在一个很好的位置上。
很多人觉得静态语言不够灵活，但我觉得这是 Java 能被众多软件厂商接受的重要原因之一，它能够适用于庞大的研发团队。试想一下，如果我只能在运行时才知道一个接口返回的是什么，那上下游之间得要下多少成本来保证传递正确的内容？而静态语言绝大部分内容都是明确的，就算有问题，多数也能在编译时发现。
另外，我觉得面向对象思想的传播，也是 Java 被广泛接受的原因之一，在那个时候说起 OO，大家第一想起的就是 C++ 和 Java。根据 OO 理论设计的系统能够几乎“无缝"地用 Java 实现出来，再配合一些工具，代码生成更是大大提升了开发的效率。在大规模工业化的开发过程中，这是非常重要的。
最后，我想强调一点：通常大家说起 Java 都是指语言，但我们不能把 Java 狭义地理解为 Java 语言，个人认为 Java 这个平台才是关键，才是真正获得成功的东西。 Java 平台的开放和包容，让它不仅可以运行 Java 语言开发的代码，还可以运行 Ruby、Python、JavaScript、Scala、Groovy 等很多语言写的代码，因此其他语言的开发者可以很轻松地切换至 Java 平台。
InfoQ：现在新的语言层出不穷，其中不乏一些深受欢迎的语言。那么，Java 现在有哪些新的挑战？您对 Java 9 有怎样的期待？ 丁雪丰：关于这个问题，我以前在 InfoQ 上发表过一篇文章《作为一名 Java 程序员，我为什么不在生产项目中转向 Go》，以 Go 语言为例，我认为这是一门非常出色的语言，在一些场景下有着比 Java 更好的表现，但正如我上面说的，Java 不仅是一门语言，更是一个平台，它有着完善的生态环境，很多特性虽然语言本身不具备或者不尽如人意，但生态环境中总有更好的解决方案。
而且，真的在实际的生产中，语言本身往往只是考量的众多因素之一，我能用某种语言很快地完成一个功能的开发，但能不能让 10 个人、50 个人都又快又好地以一样的标准完成开发工作呢？有一套好的设施、工具甚至可执行的标准会容易很多，所以我认为 生态环境要比单独的语言本身更为重要。
说到 Java 9，很多人都会期待模块化，但其实我更希望 Java 9 出来的时候，Java 8 可以再普及一些。总是会有人觉得新东西不太靠谱，要用低一个版本的东西，觉得用的人多了，经过时间检验了。君不见，如今还有很多运行在 Java 6 甚至是 Java 1.4 上的系统，什么时候能让大部分人感受到 Java 8 的魅力呢？
丁雪丰：说起 Spring 就不得不提 Rod Johnson，Spring 诞生于他的那本《Expert One-on-One J2EE Design and Development 》，而他的另一本《Expert One-on-One J2EE Development without EJB》真正让 Spring 红透半边天。
Spring 最早诞生在 2004 年，个人认为在 2.0 版本以后，也就是上面提到的那本书出版后国内的开发者才大范围地接受 Spring，当时国内的满江红社区还组织翻译了大量的开源框架的官方文档，包括了 Spring、Hibernate、Seam 等等，这也在很大程度上推动了这些框架在国内的落地。
（注：Spring 框架是开源的 Java/Java EE 全功能站的应用程序框架，以 Apache 许可证形式发布，由 Pivotal 开发并维护。）
再往后，Spring 的版本不断迭代，其核心的部分并没有太多的变化并开始趋于稳定；不过逐步开始发展 Spring 的子项目，诞生了类似于 Spring Data、Spring Batch、Spring Integration 等诸多周边的子项目，将很多功能都从 Spring Framework 中移到了子项目中。
现在到 Spring 的官方网站上，各种项目不下 20 个，所有的这些子项目中，近期最热门的当属 Spring Boot 和 Spring Cloud。这一对搭档极大程度上降低了使用 Spring 快速开发生产级系统的成本，而且能够方便地使用各种成熟的技术与设施，使得开发此类系统的门槛大幅降低。
InfoQ：能否向大家介绍下您所理解的 Spring 技术？Spring 框架有怎样的特点？它最适合怎样的项目情景？ 丁雪丰： Spring 已经不再仅代表一种框架，它与 Java 一样，都已经有了一个完整的生态环境（比如上文中提到的众多子项目）。
先聊聊狭义的 Spring，即 Spring 框架。从最开始接触 Spring 1.x 起，它特有的模块化设计就让人感到学习和使用起来没有负担，因为我只需要去掌握需要的那些模块就行了，比如 Spring Core、数据访问、MVC 等等，至于 Remoting 那些功能，大概有个印象就行，知道它有哪些功能，在需要的时候去翻看相应的文档就好了。
在后来的演进过程中，Spring 框架变得越来越大，显得有些臃肿，但开发者们还是只要关心自己要用的那些东西就好，了解下新的特性和用法，而且它在很多情况下还是能够完美兼容的，所以升级时的负担也不会很重。
至于其他的特点，网上有很多资料，我就不再在此赘述了。
而广义的 Spring 则是 Spring 的生态，Spring 将很多功能拆散到众多子项目中，每个子项目专注于某个特定的功能，比如 Spring Security 就专门处理安全相关的问题。并且，多数子项目都发展得很不错，市面上至少都能找到基本单独介绍一个子项目的书。
正如我前面提到的，在所有这些子项目中，Spring Boot 和 Spring Cloud 是近期最为热门的项目，早期 Spring 还有一个 Spring Roo 的项目，用来生成项目工程和各种代码，但后来 Spring 团队发现代码生成并不是一个特别理想的做法。在 Spring 4.x 引入了大量注解，提升自动化配置能力，Spring Boot 正是在此类能力的基础之上，大大降低了需要编写的配置和代码量，它 替开发者做了绝大部分选择，让开发者能更专注于业务本身。
个人认为，但凡 Web、后端服务这类的项目都可以放心大胆地使用 Spring Boot，哪怕是一整套项目都使用 Spring Boot 也不会有太多问题。比如国外的 Netflix，国内的淘宝、支付宝，都是几乎全部由 Java 使用，广泛使用 Spring 技术，不少也在使用 Spring Boot，甚至是向 Spring Boot 和 Spring Cloud 贡献代码。
但 Spring 也不是万能的，比如涉及硬件的一些场景就没什么发挥余地了，在开发板或者嵌入式设备上，还是选择更合适的东西吧。
InfoQ：您怎样看待框架？它是很好的工具，但是一定程度上是不是也有不足和束缚？项目多大之后就建议一定使用框架？ 丁雪丰：在我看来，框架要做的事就是把大量最佳实践固化下来，降低开发者的使用成本，让大家能聚焦于做什么，而不是怎么做。比如 Mina 和 Netty 就把怎么写出好的网络通信代码的经验固化了下来，Google Guava 就把 Google 里大量 Java 的最佳实践变成了人人可用的东西。
其实使用框架也确实有束缚，一旦你使用了一种框架，那你的系统在很大程度上来说有被绑定在上面了，切换的成本是非常高的。举个例子，在存储层使用了 Hibernate 来做 ORM，之后想完整切换到 myBatis，几乎就是重写整个 DAO 的底层。
不过，情况也并非总是这么糟糕，也有容易的，比如一开始使用 Log4J 1.x 作为日志框架，后续想切换到 LogBack，不用把所有日志的包都重新 import 一遍，使用 log4j-over-slf4j 就好了。
至于项目多大之后使用框架，个人认为，在条件允许的情况下，只要能够帮助降低开发的复杂度，提升效率，无论什么规模的系统都可以使用合适的框架。
InfoQ：能否和大家分享下您的 Spring 学习历程？新手是否建议直接学习框架？框架需要理解掌握到什么程度？学习框架需要源代码？ 丁雪丰：我自己最早就是翻译 Spring 的官方文档和书籍，从 Spring 1.x 到 2.0，再到 2.5。翻译的过程让我对整个 Spring 框架有了比较多的了解，很多功能虽然一时用不上，但翻译和审校时总是会看个几遍，于是也能了解个大概。再到后来各种子项目则是在新出来时做个了解，实际工作中需要用到时再详细阅读文档。
另一方面，多做一些分享和交流，准备分享材料的过程也是对自己知识的梳理和总结，会有很多意想不到的收获。比如，之前准备一个 Spring Cloud 和微服务相关的分享，大部分网站和文章都会拿 Eureka 做例子，我特意去用了下平时不怎么接触的 Spring Cloud Consul 服务发现。
至于后面两个问题，我觉得是水到渠成的事情，不用刻意去纠结。
对于新接触 Java 的同学，学习基本语法自然是第一步，随后需要找些小项目来练手了，这时自然就会接触到一些框架，所以新手接触并学习框架是件很自然的事情，不用去想该早点或者晚点。
平时把框架用好就行了，遇到问题会有思路去排查和解决。二八法则可以说是普遍适用的，对一个框架了解 20% 就能满足大部分的日常需求。可这并不能算是用好，因为你总是会碰到些这样那样的问题，出现问题时自然就会去翻看对应部分的代码，所以学习框架的源代码也是迟早会发生的事情。
8 月 26 日，中国首届的 Spring 技术大会将盛大启幕，在这里你会遇见十余位中外技术大咖，聆听 Spring 生态 10 余个技术主题分论坛，一同探讨 Spring Boot、Spring Cloud、Cloud Foundry、Cloud Native、DevOps 和微服务的真知灼见和实际案例。
戳「阅读原文」或识别下图「二维码」了解更多详情！
