对于新事物的接纳，常常是在痛楚的压力之下。很大程度上，这正是Java所经历的。Java的产生，是对当时很多系统的缺陷所做出的反应。Java技术通过下面的手段减轻了开发者的痛楚：1）顾及了网络计算方面的需求，是应运而生。2）在技术能力的抉择上，保持良好的品位，顾及了大众的心理。3）采用适度强制性策略推行设计决定。此外，Java技术已经成为大学教学中的主流，这同样保证了Java开发者队伍的不断壮大。

　　但是最重要的一点是，再没有另一种程序设计技术，能够像Java那样允许程序员开发基于Internet的不同平台之上的应用程序。Java平台在这方面的杰出表现，已经被大量的实例证明。Java已经成为Internet上的缺省应用程序平台，JavaAPIs也成为Internet应用程序开发的天然平台。

　　Stroustrup：微软和Sun把大笔的金钱扔在Java、VB和C#中，并不是因为他良心发现，也不是因为他们真的相信这些语言能够带给程序员更美好的生活，而是利益使然。

　　有一个说法，认为软件工具厂商如果能够把应用程序开发者的专业技术任务负担起来，将获取巨大的经济利益。我对其背后的经济分析颇为怀疑，我认为这很难成为现实，特别是当应用程序开发者使用开放的、标准化的工具时，他们可以有多种选择，从而使上面的想法更加不可能。

　　多年以前，C++就已经具有泛型能力（也就是templates和STL），有运算符重载，有枚举类型？我们会不会在Java的未来版本中看到这些特性？Java是不是应该纳入这些特性呢？

　　Strousturp：从1988-89年起，C++就已经有了templates。但是我们花了不少时间来了解如何最好地运用这个工具，早期各厂家对于template的支持在品质上也有很大的差异。有些编译器厂商动作迟缓，至少有一个主要的编译器厂商（好像是指微软，微软在VisualC++4.0才开始支持template，在此之前一直声称template是过于复杂而又没什么用的技术，时至今日，VisualC++对于template的支持在主流编译器中都属于最差的一档——译者注）暗中鼓励声名狼藉的反template宣传，直到他们自己终于学会了这项技术为止。直到今天，对于template的支持在品质上仍然有待改进。

　　你上面提到的那些特性，我认为Java（还有C#）应该，也肯定会逐渐引入。那些对于程序员来说最有用的语言特性和概念，将会逐渐集中，成为各家主流语言的必然之选。也就是说，我认为类似析构函数和模板特殊化之类的机制，远远比枚举等机制重要得多。

　　Lindholm：Java技术成功的原因之一，就是很清楚哪些不该做。我们得多问几个为什么：这项特性是不是必不可少？增加它会带来哪些开销？运算符重载是C++中一项极其强大的特性，但是它也大大增加了C++语言的复杂度，很多人都难以招架。Java在各种可能的权衡之中，做出了明智的抉择，找到了能力与需求之间的完美平衡点。

　　当然，Java也会发展，而且最重要的是，现在是开发者们在推动发展。Java增加泛型能力这件事，很好地展示了Java是如何通过整个开发者社群的参与，在权衡中决定正确的平衡点。关于增加泛型类型（generictypes）的“Java规格申请”（JavaSpecificationRequest，JSR）已经进入JCP（JavaCommunityProcess）程序，而且已经开发了很长一段时间（参见http：//java.sun.com/aboutJava/communityprocess/之JSR-014）。现在，在JCP中，有超过80个JSRs正在讨论中，这充分体现了整个体系对开发者的积极反馈和高度合作，这正是驱动Java平台不断进化的动力。

　　发展vs.革新（Evolutionvs.Revolution）

　　C++是一种发展型的语言，Java和C#似乎更像是革新型语言（它们是从头设计的）？什么时候，革新型的语言才是必需的呢？

　　Lindholm：Java技术并非凭空出世，反而更像是发展型的。Java所有的特性，在Java平台推出之前，都至少已经存在于另一种环境之中。Java的贡献在于，在众多的特性和权衡中，做出了合理的选择，使得产品既实用，又优雅。Java技术对于程序员的态度是：抚养，但不溺爱。

　　Stroustrup：从技术上讲，我并不认为Java和C#是什么“从头设计的”革新型语言。倘若Java是从技术原则出发，从头设计，大概就不会模仿C/C++那种丑陋和病态的语法了（不必惊讶，Stroustrup在很多场合表示过，C++采用C的语法形式，实在是迫于兼容性。他本人更偏爱Simula的语法——译者）。