《Beyond Java》（一）

　 以下内容来自学校专业英语课程的作业——翻译《Beyond Java》一书，分小组合作完成，偶然整理磁盘时发现，索性贴上来，也不枉费曾经的辛苦。当然一切版权归原作者和出版社所有，本人并无冒犯之意，如果侵犯他人权益请及时告知，我第一时间移除。

       ＰＳ限于水平，问题难免，请见谅

  第一章（By Huihui）

1       猫头鹰和鸵鸟

我所认识的一些划皮艇的人都有求死的想法。他们不顾一切的突破第五关。似乎在开始穿越瀑布之前他们就已经收集了在船下面的朽木。这一障碍相当于给船设了个陷阱，河水的力量会把船员拖下水。他们就像鸵鸟，不顾危险的把头伸进沙子里。

然而也有另一种划船者。在我刚开始划船的时候我就观察好了一切。在助跑前的45分钟，我会在最普通的二级小波浪前就停下来检查，并架起安全绳索。我经常超时，为了赶在黄昏前完成，所以不得不拆掉底部。现在对于大多数小的急流，我很少走出船去侦查了。在某些地方，只是因为这不可行。我用追赶划法代之以改善我的状况，而追赶划法发明于东南狭窄而险峻的河流地带。我不喜欢这样划是因为我喜欢冒险。事实上，我已经锻炼了一种能感知危险最有可能发生的地方的直觉。而我这样划是因为它能将侦查时间聚集在我最需要的时候。这些划船者就像是猫头鹰。

总结如下。我经常忽视风险，包括会产生微小后果的或是很少发生的，因为与风险打交道是不明智的。处理风险可能需要太多精力、金钱或时间，这使我开始了另外的冒险，将我带回到了猫头鹰与鸵鸟的处境。通常，这两者之间有巨大的差别，但是有时候，猫头鹰在评估风险的时候会变得自负或犯一些小错误，说服他们自己在没有侦查的情况下冒险。这样的事情发生在我身上过。有一条小溪我走了几百次了，伴随着一些变化，比如河流水位以及溪水河床在水灾后会升高。在猫头鹰与鸵鸟之间也有一条比较好的界限。有时区分两者很困难。作为一个划船者，即使我决定在一些河流或情况下忽略某些风险，有时我也需要返回再评估风险。这是这本书的主题。

1.1       无知是美德

在很多方面，划艇就像编程。我认识到了一个难以置信的骗局。简单的忽略大多数问题能惊人的提高我的效率。只需要一点点的运气，那些问题经常就解决了。这一态度能帮你也能害你。许多邮局办事员和拿最低工资的速食店雇员领悟到了同样的技巧，这些技巧对他们解决问题时很有帮助，也同样为顾客认同。这些人是鸵鸟。如果你仔细观察，你能发现一些忽略猫头鹰标志的可选择的明智应用。事实上，我发现程序中大多数问题仅仅是潜在的问题。如果你读过我的随便哪本书，你会发现我鼓吹反对过早乐观的危险，并模仿流行而灵活的YAGNI原则：“你不需要它。”我通常忽略那些声称可以节省我时间的臃肿的框架，而相信我自己的直觉，采用更简单的解决办法。

更重要的是，Java能做我需要的每件事，所以我已经很久没有看过在它的边界之外的世界了。无知是福。我知道一些语言更加动态化，效率更高，但是最后，Java似乎总能胜出。现在已经有了成千上万个框架，可以帮助做任何事，从为核子反应堆设计的系统到在一个电动指甲刀上编程实现嵌入式控制器。很多最好的框架甚至是免费的。我总能发现Java开发者做了我所需要的。我知道那些人已经能实现并解决一些大问题了。我相信我的顾客也将感到安全和可靠。简而言之，Java集合以及范围已经打败了所有能提供的可供选择的东西。所以我放弃了寻找。并且我很高兴我做到了，因为这让我可以集中精力做咨询业务并且让我的客户满意，而不是费尽心力研究每个新的问题。

当一个具有优势的语言或技术处于最佳时期，在按照你的喜好忽略可其他选择时会是一个好的无知阶段。图1-1表达了我的意思。当一个新的语言在Java或者C++的强大力量及优势下出现时，你能暂时的忽略选择。但是如果你不能正确鉴别循环的结束，你可能会失败。突然的，你的竞争者会占据优势地位，他们拥有更好的性能导致更好的质量，提高的生产力以及更多的顾客。当你进入过渡时期，你最好开始留意了。

图1-1 在一段时间内，无知是有效率的，但那段时间的结局是不可预知的

我可以毫不脸红得承认我喜欢将我的头埋在沙子里。那很容易，有效率而且安全。我敢打赌你们这些Java开发者中很多都像我一样做。你们可能有自己的理由。生活在这样的避风港里当然更容易做不出什么好的额外的东西。从没人被IBM炒过鱿鱼，这可能让你觉得更安全。（好吧，也许OS/2的组件经纪人不是一个好主意……）可能在你相信不会贬值的技术上，你有相当大的投资，如果在你的技术集上投资甚少，那么你可能是正确的。在基于某一语言做了长时间项目或团队后，你可能要像Java的孪生双胞胎一样跃进。正如我的理由，这是合理的。

1.1.1        根基被动摇

在享受了无知长达五年甚至更久之后，我有了一个被彻底打击的经历。。我开始了一个新的方向，这个需要最多产轻量级架构中的三个，而我认为这来自于不断应用的网络发展。它们是：Hibernate, Spring, and Web Work。我知道对于这种事情有稍微能提高效率的环境，但它们既不能测量（就其复杂性和性能而言），也因其不太受欢迎而不能证实它们的风险。

我和我的搭档决定我们应用中的一小部分用Ruby on Rails——一个基于web编程的非常高效的框架来做。我们这样做不是为了取悦我们的顾客，而是为了满足一点点聪明的好奇心。结果令我们大吃一惊：

l        由于重写，我们可以更快的编程。快了很多。Justin，我的主要编程员，只花费了几个晚上就完成了用Java需要四个月完成的活。我们估计我们的效率提高了5至10倍。

l        我们写了四分之一的代码；如果算上配置文件的话是五分之一。

l        高效的产量在我们完成了重写后仍然保持着。

l        这个应用的Ruby on Rails版本跑的更快。This is probably not true of all possible use cases, but for our application, the RoR active record persistence strategy trumped Hibernate's Object Relational Mapping (ORM) , at least with minimal tuning.

l        与关注一个安全的java基础相比，顾客更加关注于效率。

如果你能很好的想象，这个彻底的震撼了我的世界观。我现在疯狂的试着追上它。看来河流的情况在我没有注意到时已经改变了。我必须开始再次侦查。

1.2       沸腾的青蛙

让我们换种方式想想。你一定听过如果把一只青蛙放在热水中，它会跳出来，但如果你慢慢的将温水煮沸，青蛙将安心的死去。当然，这就是我在这本书里想要引起的争论。我们周围的水在升温吗？注意在我介绍的最后，猫头鹰和鸵鸟在后果上是完全相同的。它们可能没有意识到，但是动机完全不起作用。如果水开始沸腾了，或者河流的情况改变了，它们都将死去。

在这过去的一年中，我曾决定唤醒我周围的环境去测试我周围的水。我学了Ruby和面向方面的程序设计（AOP）。在检查了温度以后，我认为水实际上在升温。现在它还没有煮沸，但我并不知道它会不会煮沸。但我知道我暂时必须密切留意着温度，而且我希望能让你也同样做。让我来告诉你为什么。

1.2.1        危险标记

我们所编写的许多应用软件用都是在一个数据库上加一个基于web的前台，有时还有附加的商业规则，有时没有。然而，在反反复复的解决这个问题长达五年之后，我们仍然不能在Java空间中快速解决它。进一步说，大多数的Java框架开发者是在进行增量的变化，这不能彻底变革web的发展。有必要重新组建一个团队用正确的方式去解决这一问题。组建一个团队的话，比如说COBOL程序员，是几乎不可能的。这个语言差异太大，框架太广，前景太不稳定了。在这个基础上甚至是经验丰富的开发者都需要惊人数量的代码去实现一个简单的应用。

 

1.2.2

1.2.2 .1  复杂性

       Java好像正在偏离它的基础。可能你解决最困难的问题是更容易了，但是创建简单的web应用程序却比以前困难多了。James Duncan Davidson称这一问题为易近性。当Java出现不久的时候，要创建一个基本的小应用程序你不必知道很多。现在，如果用最流行的架构来创建一个简单的web应用程序你需要知道很多。

       事实上，开放资源工具正在尽可能的巨大的改变着Java的效率。强大的工具像Hibernate 和Spring能让你用很少的力气建立企业级的应用程序。但要精通那些工具可能要花上一整年。AOP也会有所帮助，它能让你用清楚的旧的Java对象（POJOs）写你的商业规则，并将服务比如安全和事务预先封装到包里。然而这些抽象性的东西对于新手来讲使他们要在不断上涨的河流里面航行。我的问题是：多高是太高了？我想对于大多数新手来讲我们已经太高了。当我和顾客讲他们可以重新训练普通的COBOL程序员Java时，我已经感到不舒服了。这样的话要学得太多了，而且太费时。

       过去，复杂的问题引向更高的抽象性。当电脑对于人们来讲已经太大而不能用电线编码时，专家开始用机器编码编程。当那些程序太大以至于人们理解不了时，他们用汇编语言组织机器语言与数据。复杂度的提高导致高级别的语言，结构化编程以及面向对象编程。我的观点是这条复杂度的河流上涨会爆发水灾，迫使我们采用新的抽象，早用比晚用好。

1.2.2.2     快速变革

在过去的三年中，Java身上发生了惊人数量的革新。你们经历了一场变革，从重量级容器，比如EJB，到轻量级容器，比如Spring。你很可能不再坚持EJB或是JDBC，而使用iBATIS， JDO，或者Hibernate。你也许已经感受到了从Structs转变成诸如Tapestry之类的明智。我的经验是大多数革新是由需求驱动的。我的理论是当复杂度达到一定阀值时，革新会快速的增加。我所有的支持这一理论的唯一依据是依据现实情况的：

l        过于强大的新的如山般的持久化框架

l        大量繁殖的MVC框架

l        容器数量的增长

l        XML绑定框架的快速引进

我的意思是革新往往伴随着需求。当我们有了一样东西它是正确的或是足够接近的，比如Ant 或者JUnit，那么直到它不适合我们的目标我们才会抛弃它。

在Java中建立最简单的web应用要学很多，经验丰富的开发者也许无法理解这一痛苦的过程。他们中的很多人会抱怨我夸大了这一问题。如果你是他们中的一员，你能否找到一个聪明但没有什么经验的Java开发者，这个开发者正在学习你在开发企业web发展中所需要的所有应用，请你会见下他。问题是双重的。首先，它是难的。其次，失败的后果是可怕的。如果你一旦选择了错误的工具，或者在一个大项目上使用过时的技术而卡在那里三年，那么当你开始下一个项目时，你仅仅从刚才的地方接着开始。The implications of the churn are staggering.对我来说，那可能意味着编码需要上升到更高一级抽象，而它在Java中已经不能找到了。

1.2.2.3     不自然的延伸

你可能在日益延伸Java，超过了他的原定方向。你用普通Java编写的对象已经不够了，这是个事实。我确信试着用Better，Faster，Lighter Java去把所有的服务和应用编码成商业对象是愚蠢的行为，而且继承也不可用了。你得使用技巧，像编译时间字节代码增强或运行时利用代理代码生成，以使对象透明。现在你将Java延伸到了超过了它的既定目标，并且是向恰到好处方向好。同时你也增加了入门的障碍。问一下随便哪个新手谁愿意试着两次用Hibernate的自动加载或者是Spring的代理去研究同一个问题。

我还注意到了其它，更多的动态语言很少使用像AOP或是依赖注入之类的东西。那些特性解决了Java中的难题，但是像Smalltalk，Python和Ruby更有力的语言，没有同样的痛苦。

我不是指这些是不好的技术。就简单性和力量而言，他们确实破坏了最接近的好的其他选择。他们在解决难题。只是你的思维只能学那么多那么快。Java正快速成为优秀开发者的有效工具集。嗨，也许这就是程序设计的方向。我只是想说这种不自然的延伸是你应该感受你周围水温的又一线索。

1.2.2 .4  语言进化

Java 5被极力吹捧为Java五年来最具创新的主要版本。我同意他确实有着深远影响。我不是很确信所有的影响都是积极的。我有规律的参加一个叫做NoFluffJustStuff的会议。专家和座谈小组作在一起并回答问题。我最喜欢的一个问题是关于语言的新特性的。所有座谈小组成员一致认为被贯彻执行的一般的是一个糟糕的主意。他们着实令听众吃了一惊。

如果你仔细想一下，the Java generics Java Specification Request (JSR)提出了一整个一批句法来解决一个对Java虚拟机（JVM）没有相应的改变的小问题。我猜测典型的Java开发者很少人会去捕获一个强制类型转换的异常。有充足的机会。不管怎样，一个典型Java应用中的大多数对象被收集起来了。无论什么时候你用它们，不管怎样要把它们从Object转变过来。那样的话，类型安全给你像一根在燃烧饼坠落的747腰带一样足够多的保护。然而，一般语法是入侵式的，而且执行起来更糟。当越来越多的专家声称动态类型会引向更简单的应用程序以及更高效率的程序设计，当这一时代到来时，Java开发者将研究怎样对静态类型建立更强的强制性。

添加像注释这样的存在疑问的属性，这样能彻底改变你程序的语义，而不是用常规代码，同时也给你带来了各种各样可能的麻烦。力量上的强大是否抵消了复杂性和模糊性的增加呢？对Java社区来说，注释带来了一个崭新的工具，从许多方面来讲也是编程模型。我不知道我们能否很好的利用注释，但是在我们研究的时候我渐渐预知到了一些主要的灾难。

我不想太早挑明。我将在3至5章更多的讨论Java的局限性。现在，只需明白Java正经历着一些真正的问题。这也许是年轻人成长的烦恼，或者是Java十周年的中年的关节炎。我只是还不太清楚，但是不断上升的水温已经引起了我的注意。

1.2.3           好的就是好的

当你阅读这个段落时，我不是说java语言的号手正在完成“Taps”的最后很少的一点注释。并不是说出厄运和黑暗，我宁愿告诉矛头和鸵鸟之类的人，打起精神，观察并倾听。像这样看：一个可信的替代者出现时时机成熟。在出版的时候，Java仍然是山中之王。事实上，充满力量以及带有强实性的动机仍然驱动着在Java上的新的投资：

l        Java社区是充满活力的。你能找到天才去攻克Java中的难题。你还能找到支援队员，像懂得Java的销售人员及项目经理。

l        大多数大的商业卖主都支持Java，或是一个接近的延伸物（C#）。结果，你能为Java买到应用程序，服务器，组件，工具，服务，甚至是管理控制台。

l        开放的来源本身是一个兴旺的力量，并且它每天都在难以置信的推进改革。

l        学术机构教Java发展和研究很多与java有关的问题。我近来进行一项研究，即对一个工具产生影响能预测java的表现，比如UML简图，这个是在一个大学的研究实验室进行的。

l        JVM本身是一个强大的革新并且允许从未有过的可移动性。一些专家相信JVM将比Java语言本身更重要。

现在你可能相信了，正如我之前所说，所有的整个充满活力的社区战胜了任何在最极端问题中语言优势。甚至就算你确实发现了一个这样的问题，谁是必须的替代者呢？怎样才能找到足够的开发者去达到最重要的阶段？你可能会想：面对它吧Bruce，有.NET和Java呢，而且.NET在设计上像极了Java。采用.NET就像发誓戒除麦当劳，重新定制你的饮食，每天去吃夹饼王。那之后就没什么了。

这当中很多都是事实。如果没有可信的替代者，你最好的课程就是深入研究在Java社区里找寻答案。那样的话，这就是本死书，你就随它去吧。但是请再给我多几页纸的机会，以防你太早的把它合上。

1.3       新的地平线

牢牢记住我内心里是个愤世嫉俗者。当讲到技术的时候，着实需要很大的力气才能让我兴奋起来。我还没有写过一个web服务，至少是用繁重的IBM和微软的stacks，直到2003年我才写了我的第一个EJB程序。我还没有写过一个EJB的实体bean，除非是建一个例子来反对它，而且永远不会。我现在改为更喜欢简单的架构，像REST，POJO 程序设计透明，持久化，以及Spring。即使在那个时候，我进入这个领域已经算晚的了。

对我来讲用一门新的语言更难。Dave Thomas，一个令人非常尊敬的程序员与极具天赋的老师，喜欢说你应该过两个月就学一门新的语言。而我可能平均要五年，而且我最多只是涉足了解。但是最近在我涉足的过程中，我发现了几个令人吃惊的革新。这些框架的设想足以让我从椅子上蹦出来。

我比平时花了更多一点的时间来研究新的程序设计语言中的有意思的革新。当需要新建web页面和应用服务器时，两个想法引起了我的所有注意力：元程序（像Rails中的Ruby）以及连续服务器（像Smalltalk中的Seaside）。这两个革新没有一个对Java有影响。在第7和第8章你将了解更多，但是到目前为止，足以说它们比Java的替代者们效率更高。

1.3.1        动态语言

Java语言有很多妥协。Java的许多特性适合建造操作系统的扩充以及中间件，但是限制了应用的发展。考虑下这个Ruby片段：

something = "Owls and Ostriches"
  
  

4.times {puts something}
  
  

这简单的几行代码把“Owls and Ostriches”打印了四遍。看一下这个语言的本事：

l        你不需要为打字这样的细节担心，如果你不想的话。如果它像鸭子一样走路或者像鸭子一样叫，Ruby会把它像鸭子一样打出来。这比你想象中节省了更多的时间。

l        4是一个对象。每一个事物都是对象。你能传递一个方法给4，或者一个字符串，就像系统中的其他对象。

l        {puts something}是一个代码块。你能把代码块作为参数传递，并且Ruby能让方法去处理代码块。这个结构很大的简化了像重复这类的事情，能让你在库中快速的定制一个循环的内部。

正如他们所感受到的，这些特性能使你效率更高。但是如果你添加一种动态语言的其他特征，你将很快能看到难以置信的力量及性能。许多所谓的脚本语言对于应用程序开发者来说有更重大的意义。

1.3.2        元程序

Java社区正投入更多的精力到更加清晰、熟虑、动态的编程风格上。这些方式叫元程序，因为它们在类上花了比在对象上更多的时间。有意义的是那样的话你更有优势。透明持续框架，像Hibernate，使得普通的类和集合连续不断。。AOP使你延伸了用自定义码实现的方法的指定名单，而不需要修改那个方法。这些问题就是元程序问题。

当Java专家因元程序而感到兴奋的时候，他们经常使用其他语言。需要解释吗？David Geary，Java最著名的作者之一以及JSP专家组成员，带有进攻性的学习着Ruby，并且在写一本Rails的书。James Duncan Davidson，Tomcat和Ant的创建者，离开了Java社区去为Mac环境编码Objective C。正如你所见，Justin Gehtland和我在利用Rails实现一个基于web的应用程序，这个程序是用于启动的。

试着将元程序想成一个高级别的建造者。比如Ruby on Rails，发现了数据库方案中的列及关系，并使用那个数据为一个web应用建立了模型，视图及控制器。这个环境的特征是惊人的：

l        它非常的高效。在某些问题上，它很容易就比Java竞争对手要高效5倍。

l        它是灵活的。一些解决办法建立了默认的应用程序并允许公共扩展点。Rails有一个默认的应用程序，你可以扩展它，看上去就像你自己写的一样。

l        它减少了副本，一致性提高。

对我来讲，对于企业应用程序开发，语言或者环境最重要的特性是性能。我想要每一行代码都更卖力的工作，我想那转化为性能。在部署之后我不停止测量性能。如果你的小应用程序不可能维持下去，你将失去所有你得到的。因为这些理由，我喜欢Ruby on Rails，我将在第7章更详细地讨论它。

1.3.3        不间断服务器

Java的web开发者花了不可置信的大量的时间在管理状态，线程和Back按键上。随着站点变得更加动态及复杂，这些问题也变得明显更困难了。在Smalltalk现今有一个复流，它的大多数都以一个称为海滨的架构为中心。自不间断维持状态以来，给予持续的服务器在管理状况上不存在任何管理状态问题。它们同样容易的处理了Back buttons以及线程。这个框架使用了一个被称做持续性的语言特性，来在web应用程序中维持状况。

1.4       前提

我不打算说Smalltalk或者Ruby以后将掌控世界。甚至我不想说还会有谁会再次达到Java的成功。但是我不相信Java使永恒的。五年以来，忽视Java的界线是一个好的策略，但是没有哪个语言能永远占据领导地位。到现在，应该将这本书的主题呈现给你了：

l        Java正在偏离它的根本。核心的企业级问题也许更容易解决，但是最简单的问题却变得更难解决了。还有……

l        Java已经有衰败的迹象，一些有趣的变革开始在Java以外出现了，所以……

l        现在是时候开始重新关注了。

打起精神。从阅读这本书开始。当你做到的时候你会高兴的。