今日Java:Cay Horstmann访谈

　　InfoQ：是这样。小型购物网站的问题也许在于应用呈指数型增长时是否有必要从Node或Rails切换到一个“更正式”的环境。

Horstmann：是的。在我看，对JavaEE敬而远之并非幸事。即便开发小型项目，Java也常常能相当快速且轻松完成任务。如今我所接手项目的用户数量多几千或上万，不会有百亿之众。我发现无论项目大小，很多人一概无脑选用像Rails之类的技术。这样做，你必须去找会Ruby的人。Rails的那套技术是全新的，而找到Java开发者则相当简单。

　　InfoQ：你说的情况更多针对当前开发者还是大学新人？

Horstmann：大学新人。Java在教育中相当普遍，而学过Ruby的人会很难找，无论这些人学Ruby是自娱自乐，还是工作所需。

　　InfoQ：你如何看Java随时代变迁而发生的变化？

Horstmann：任何一种想经久不衰的语言都应该具备用户现阶段需要的特性。比方现在，并发情境下，函数式库更为时代所需。没有这些特性不是不行，但这些特性会为Java 8锦上添花。就目前所支持的特性而言，Scala可能更胜一筹，但Scala有其他问题，比方说复杂性。

　　InfoQ：也就是说，Scala用户更多看重JVM平台，而并不想使用Java。

Horstmann：如果你了解所做的事情，Scala可能会更高效。一半或更少的代码就足够表达你的想法。有些在Java中你会因为繁杂而不愿尝试的方法，在Scala中就很简单。我很喜欢Scala，但我偶尔也会为之担心。（用Scala编程时，）如果走错了一步，你可能要抓耳挠腮一会了。

多数情况下Java简单一致。我甚至记不得最后一次自问“Java语句暗中做了什么”是什么时候。这条特性很有价值。

　　InfoQ：特别是在公司或团队环境中，从事人员会超过两三个。要求相关人员记得所有资料会十分困难。可预测性却是必须的。

Horstmann：确实。你不会记得C++ 11的所有特性。那种语言太繁杂。

　　InfoQ：Ruby之类的语言呢？我是说你可以立刻着手，之后呢？

Horstmann：Ruby本身并不提供更多选择。Rails才使之真正规范化。也许你会花好几天冥思苦想某些Ruby谜团，可专家会告诉你，“这是它两年前的运行方式，现在的运行方式有很大不同。”

　　InfoQ：就Ruby on Rails所能提供的优点而言，你认为那些自称最小化Ruby on Rails的Java框架是否有效？

Horstmann：现在看来Rails解决过很多并无解决必要的问题。如果客户端通过移动设备、tablet或HTML 5提供用户界面，用Javascript做渲染，Rails的HTML模版会无用武之地。所以将来Rails是否会再度高速增长，我不知道。

　　InfoQ：书中是如何处理Java选材问题的？现在分上下两卷，如果知道当前语言的规模，你会作哪些调整？挑选主题的标准是什么？

Horstmann：因为要求涵盖所有内容，最初书的主题很多。若干年前初次设计时，Swing和RMI是热点。这会是讨论这些内容的最后一版。下一版，即Java 8版中，我会更关注人们想达成的目标。Swing或RMI在下一版中仍出现是不可想象的。最后一次用到这些技术是多久之前了？

　　InfoQ：书中涵盖了整个语言，显然不是简化版。开发新手或Java用户会对此表示感激，还是只关注卷一？

Horstmann: 一半以上的读者没买实体书。查阅销售记录时，我发现Safari Books Online是主要销售途径。程序员在那儿每次读几页。

　　InfoQ: 保持书中内容系统有序很重要，而书的厚度并不重要，读者可以从书中主动获取想要的知识而不必通读全本。

Horstmann: 确实如此。新版中也许不包含Swing，但Safari仍会留有旧版。所以绝非Swing到了世界末日。实际上我更惊讶于电子版发行后快速增长的销量。计算机市场中这一现象已持续了一段时间。

我并未试着加入一些孤立环境中很难理解的长例子。有些书会这样做。他们渐渐扩充实例，这会让跳读变得很难。

我试着让每个人能直接从感兴趣的那一章节读起，而不必一定要先读过之前的六章。

　　InfoQ: 你已展望过Java 8。在你看，最需要或者最应该被关注的特性是什么？

Horstmann: Lambda表达式毫无疑问是一个。容器方面的改进是一个。这些会让日常开发变得十分简单。为充分利用多核而不加大程序员开发难度，并发方面的变化也很重要。Java 8和Scala会让这一工作变得优雅。程序员呼吁，“噢，我想所有事情都并行。”你恰好有一种并发的解决方案，通过操纵一个类似Linq的队列轻松实现并发。这点将会十分重要。

　　InfoQ: 基本数据类型有必要消亡么？研究时我发现基本数据类型和包装类型间兴许存在共性。

Horstmann: 那就太好了。若干年前，我问过那段时间正研究这个问题的Neal Gafter：即便基本数据类型相比范型添加了一整层复杂性，基本数据类型为何仍未消亡？他说存在这样一种无法等同int和Integer的情况。有人创建了类似Integer(42)的新对象并把它当锁来使用。这种情况下，如果你无法区分两个不同的Integer(42)，代码将会失效。

绝对的向下兼容看来并不理性。可交换情形下，int和integer的差别应当是VM所能识别并优化的。

同样，对VM而言，int数组和integer数组间的交换同样困难。

现在看来，整型和浮点型数值在最初就该当对象看，但20年前，基本数据类型听上去是个好主意。

　　InfoQ: 初次向学生介绍Java时，你会选用Integer么？

Horstmann: 不会，我用int，因为很多库都用int。我不会用太多时间区分两者。用容器时，自然会考虑包装类型。实际上这并不打紧。难道你会经常用ArrayList存储整型？

Java主要关注两方面。一方面，Java门槛低，理解它无需博士学位。另一方面，Java库非常庞大：总会存在一个完成任何你想完成功能的Java库。

很多语言不具备这样庞大的扩展库。比如Python，和Java比，Python的库相当局限。

和Python比，Java还有一个好处在于向后兼容性。我赞成Python3的规范和优雅，但我不知Python2会坚持多久，而兼顾两者并不好受。