Java 开发环境的过去、现在和将来(初稿,略有改动)

(特此感谢Kent Beck先生的鼓励和陆广先生的指点)

 1995年3月23日，San Jose Mercury News登出一篇题为"Why Sun thinks Hot Java will give you a lift"的文章，在那篇文章里预言Java技术将是下一个重大事件，这个预言现在看来并不仅仅是商家的宣传伎俩，虽然文章是当时Sun的公关经理 Lisa Poulson安排撰写的。从世人知道Java那一刻起到现在，算起来已经过去整整十年，回顾过去的十年值得总结的东西可以有许多，但在这里笔者只想就Java 开发环境谈些个人的想法与朋友们交流一下。

现在的软件开发人员在整个软件的开发生命周期里，也许会根据需要使用各式各样的开发工具来完成相对复杂的开发任务，而在几十年以前，人们还只是使用文本编辑器、编译器和Debugger进行开发，对于这个阶段的开发环境人们称之为CLEs(Command Line Environments) 。而当人们发现如果将那些单独分开的开发工具集成起来就可以有效的提高开发效率时，IDEs(Integrated Development Environments)就出现了。第一个IDEs也许可以追溯到1964年的Dartmouth Basic，尽管这有争议，它是作为Dartmouth Time Sharing System的一部分，在John Kemeny 和 Thomas Kurtz指导下建立起来的，这套系统一直使用到1999年。尽管这40多年以来，开发人员的开发环境几经变化、不断进步，从早期的集成开发环境 IDEs到扩展开发环境XDEs(eXtended Development Environments)再到协同开发环境CDEs(Collaborative Development Environments)，历经了几个不同的阶段，但开发人员使用开发环境的目的始终就是一个：提高开发效率。Java的出现尽管只有十年，但其开发环境也大至经历了从CLEs到IDEs再到XDEs这三个阶段，现在即将进入CDEs阶段。在上述Java开发环境发展过程中，有许多值得我们大家关注的地方。

Java开发环境的历史回顾

纵观过去十年Java开发环境的发展，大致可以粗略的划分为如下几个阶段：

• 1995              命令行开发环境CLEs
• 1996 - 2000 集成开发环境IDEs
• 2001 - 2004 扩展开发环境XDEs
• 2005 -           协同开发环境CDEs

1995年，不平凡的一年，这一年Java 获得了成功。可令人尴尬的是在1995年并没有一个令人满意的Java开发环境，开发人员在进行Java编程时，大多使用文本编辑器编辑源程序，比如，Emacs、Vi、Notepad 等，然后再使用命令行的方式进行编译处理。那时的Java开发环境还处于CLEs时代，开发效率非常低，这不能不说是Sun的一个失误，但也预示着在Java开发工具上会有一番激烈的竞争。与Java世界即将开始的开发工具大战不同，在Smalltalk世界里胜负结果似乎已经明朗，IBM的 Visual Age for Smalltalk、 ParcPlace的ObjectWorks和Digitalk的Visual Smalltalk三足鼎立的格局那时已经被打破，IBM的Visual Age for Smalltalk所占市场分额越来越大，而当时IBM进入Smalltalk市场仅有两年多的时间。IBM之所以在很短的时间超越老牌的 Smalltalk 厂商ParcPlace和Digitalk，其中一个重要原因是IBM直接将其产品委托给一家由软件精英组成的公司进行开发，这家公司就是由软件开发大师级的人物Dave Thomas( Bedarra-Dave)创建的OTI( Object Technology International)公司。IBM在1993年进入Smalltalk市场的第一个产品ENVY/400就是OTI为其开发的，而其后包括 Visual Age for Smalltalk在内的多种产品开发OTI都参与了。为了抗衡IBM，ParcPlace和Digitalk两家公司在Java诞生的那一年进行了合并，成立了名为ParcPlace-Digitalc的公司，但事后再看这次合并，不过是徒劳之举罢了。现在各厂家的Smalltalk 开发环境中都或多或少的内置了ENVY，而随着IBM进军Java开发工具市场，ENVY的相关技术也被从Smalltalk世界带入到Java开发环境中。

1995年也是Smalltalk作为第5代编程语言从 Xerox Palo Alto研究中心走向市场的10周年，Dave Thomas为此写了一篇题为"Ubiquitous Applications：Embedded Systems to Mainframe"的论文，作为Smalltalk市场化10周年的总结，文中介绍了Smalltalk是如何利用虚拟机实现从嵌入式到大型机广泛应用开发的，而那时Java世界的人们还在为Java虚拟机的拙劣性能而苦恼，那时也许没有人会想到现在Java的普及程度早已超越了Smalltalk。

有人称1996年为互联网年，有人却称之为Java年，还有人称之为Web开发年，但不论如何称呼1996年，它都反映了一个事实： Bill Joy将Java与互联网相结合的策略取得了成功。这一年的9月Sun推出了其Java开发环境-Java WorkShop，这是一款基于浏览器的Java开发工具，但由于当时 Java在许多方面还不成熟，所以实际上Java WorkShop并不成功，同年发布的Symantec Visual Cafe由于还是采用C/C++语言进行开发，所以性能与成熟度上就比WorkShop好得多。提到Visual Cafe就不能不提Eugene Wang，因为Eugene Wang常常是与计算机间谍这个词同时出现的人物，有人甚至讲当时Symantec的老板Gordon Eubanks与Eugene Wang签约时，也同时签下了监狱里的一个单元。围绕着Eugene Wang的间谍案发生的种种事情，将Borland和Symantec两家公司不为人知的阴暗面展现在公众面前，对两家公司的声誉都带来了损害。为避免双方商业利益继续遭受损失，最后这个间谍案以 Eugene Wang向法庭交纳了一笔罚款而不了了之。Visual Cafe就是由Eugene Wang进行主要策划的，它是在同一年发布的Java开发环境中，唯一解决了与数据库连接问题的开发环境，带有一套可以与数据库相连接的组件，无需太多编程使用拖拽的方式就可完成大部分工作，这一优点使得Visual Cafe受到了Java开发人员的欢迎。这一年IBM收购了OTI公司，从而得到了Dave Thomas的弟子John Duimovich、Dave Thomson、Mike Wilson等一大批软件精英，这之中还包括"生活在技术刀锋上的开发者"Brian Barry。

1997年，由于微软垄断案，使得微软在Java开发环境上的努力受到了限制，Visual Cafe由于界面直观易用，可以很容易地连接各种数据源等功能再次受到开发人员的欢迎。这一年IBM发布Visualage for Java，它是用Smalltalk编写的吸收了许多ENVY的设计思想，比如，Visualage for Java是面向代码库的开发环境，它提供代码库和项目管理以便于开发团队在 C/S环境下进行项目开发。但由于大多数Java开发人员比较熟悉面向文件的开发环境，还不太习惯面向代码库的开发，再加上Visalage for Java对系统资源的要求比较高等因素，使得Visualage for Java一开始未被Java开发人员所认可。

1998年至2000年比较成功的Java开发环境是JBuilder，这是由于Borland较好的把握住 J2SE、J2EE和J2ME发布后，Java技术升级的时机，全面支持Java1.1和Java1.2开发平台，它还提供了多种工具方便用户从旧的平台迁移到新的Java平台。JBuilder本身80%是基于JDK1.2进行开发的，它支持JavaBeans, Enterprise JavaBeans, JDBC等方面的应用开发，可以连接多种关系数据库。为支持分布式应用开发，JBuilder还集成了 VisiBroker ORB、JSP server、数据库和EJB AppServer，并提供Open Tools API便于第三方工具集成。上述种种的优点使得JBuilder一举超越Visual Cafe，成为当时最受欢迎的Java开发环境。在众多Java开发环境中，1999年IBM发布的VisualAge for Java Micro Edition是比较有特色的开发环境，它是由Erich Gamma和与Erich Gamma有"焦不离孟、孟不离焦"之称的John Wiegand共同进行设计的，采用了Java 扩展机制，并集成了Junit测试框架，其当时所采用的架构深深地影响了后来Eclipse1.0所采用的架构。同时，通过 VisualAge for Java Micro Edition的开发，那些来自"未来世界"(Smalltalk们总认为他们来自计算机的未来世界)的软件精英们，全面彻底地对 Java技术进行了评估，得出了许多结论性的东西，这之中包括现在闹得沸沸扬扬的Swing和SWT对比。此外，Sun将其收购的NetBeans变成了开源的Java IDE也是一件不大不小的事情。

纵观1996年至2000年这五年时间里，随着Java及其相关开发应用的发展，Java开发环境也不断的完善，从CLEs进入到IDEs阶段。为了提高Java开发人员的开发效率，Java开发环境主要从两个方面进行改进与提高。一方面是提高集成在Java IDEs当中开发工具的性能和易用性，比如从最初的代码编辑器、编译器、Debugger等开发工具发展到增量编译器、组件浏览器、自动编码和用户界面的可视化编辑器等，以此减少Java 开发人员输入代码的工作量、节省编译时间，将Java 开发人员宝贵的时间花费在思考问题上而不是输入代码上。另一方面是将Java开发环境尽可能的覆盖到整个软件的开发生命周期，比如，将源代码的版本控制工具集成进Java IDEs当中，这样做的好处是Java开发人员无需离开开发环境就可以完成大多数实际工作，节省进行不同工具之间的切换时间和适应这些工具的学习时间，提高了开发效率。随着基于WEB，采用N-层结构的应用开发成为Java开发人员主要从事的开发任务，Java开发环境需要支持越来越多的技术，比如，XML、 JSP、EJB和CORBA等，这就造成了Java IDEs的规模变得越来越大，许多Java开发环境都集成了数据库、JSP Server和AppServer，软件的研究人员将上述IDEs不断膨胀的现象称为"IDEs大爆炸"。

"IDEs大爆炸"现象发生以后，有关Java开发环境是走少而精的发展方向，还是走大而全的发展方向就成了广大Java开发人员关注的问题。2001年Java开发人员达到了200万，成为每个软件供应商都无法忽视的力量，这一年JetBrains推出了Java开发环境少而精的代表： IntelliJ IDEA。 IntelliJ IDEA明确的表示只做最好的Java代码编辑器，不做什么文件都可以编写的编辑器。它关注Java开发人员的工作实际并将这些工作进行了优化，比如编写 try/catch语句结构只需简单的点两下鼠标。IntelliJ IDEA提供的活动模板可以扩展公共代码片断，语法加亮及其各种各样的快捷方式，使得开发人员可以专注于问题的解决。IntelliJ IDEA另一个特点是其编辑器具有重构功能，可以进行XP式的重构，适用于Java开发人员的敏捷式开发。由于减掉了一些可有可无的工具，所以价格上相对合理公道。当年IntelliJ IDEA击败JBuilder成为最受Java开发人员欢迎的Java开发环境，即便是Martin Fowler这样大师级的人物也喜欢使用IDEA，由此可见IDEA的优秀程度。不过2002年随着JBuilder将大而全的功力再提升一步，将UML 建模工具、JUnit测试框架以及Apache Struts等开发工具集成进来，大而全的发展方向又一次受到Java开发人员追捧。最全还是最好似乎使Java开发人员在选择Java 开发环境时处于两难状况，但实际上当Eclipse1.0发布时，这个问题已经得到了初步的解决，最好和最全是可以兼顾的，而Eclipse1.0的发布也标志着Java 开发环境进入XDEs时代。

Eclipse的出现不是从天上掉下来的，也不是某个天才拍脑袋想出来的，它是一群软件精英们集体智慧的结果。早在1998年IBM就打算开发新一代的工具平台以便将它现有的各种开发工具统一起来，并减少开发各种工具时重复的劳动，同时希望在新的平台上建立新的Java开发环境。经过一段时间的准备， IBM开始建立起一个开发团队，人员构成主要来自VisualAge for Java Micro Edition和VisualAge for Java两个项目的开发人员，选择的标准是过去10年至少开发过5到6个IDE。在开发Eclispe的过程中，开发人员借鉴了过去的成功经验，这包括：

• ENVY/Smalltalk-增量编译
• Hoops-用户可定制
• VA/java-如何使开发环境易于使用的经验
• Team/v-API先行
• Sniff-如何处理 C++的经验
• VA/microED-Java 扩展机制的架构

特别是采用了Java 扩展机制的架构一条，使得Eclipse具有良好的可扩展性，Java开发环境进入XDEs时代。不过软件精英们先进的思想要让广大的Java开发人员所接受，还需要一个过程。为此IBM联合了9家公司共同成立了一个开源组织Eclipse基金会，将Eclipse提供给开发人员使用，并在开源社区的帮助下进一步完善Eclipse本身。Eclipse在最初设计时，插件模型是静态的，不能实现插件的即插即用功能，即便是大受欢迎的 Eclipse2.1也还是静态的。所以到2004年发布Eclipse3.0时，Eclipse进行了重大改进，采用OSGi 的插件模型，初步实现了插件的即插即用功能，至此一个完美的、可扩展的开发环境展现在Java开发者面前，这时Java开发人员已经达到300万。

Java开发环境的现状

2004年Eclipse3.0的发布极大刺激了Eclipse用户的增长，据Evans Data Corporation的调查EMEA(Europe, Middle East 和 Africa )地区的Eclipse用户增加了60%，亚太APAC(Asia Pacific)地区的Eclipse用户增长了70%，而北美地区的Eclipse用户增加了90%。O‘REILLY2004年问卷调查显示使用 Eclipse的用户竟然达到70%，但这显然有感情因素在里头。经过一年以后，Java开发人员现在使用Java开发环境的状况是如何的呢？看了下面的表格里的数据也许可以了解一个大致的状况。

表1 2005年Java开发人员使用Java开发环境的状况

来源	JSurfer网站	Servlets网站	CSDN网站	O‘Reilly网站
人数	2509	5592	1000	496
Eclipse	37.31%	42.18%	54.1%	35.6%
IntelliJ IDEA	24.91%	9.87%	6.5%	13.9%
NetBeans	10.48%	12.89%	3.9%	18.7%
JBuilder	6.94%	11.85%	30.7%
JDeveloper	1.79%	3.72%	0.9%
Websphere Studio App Developer		6%	2.4%
Emacs	4.98%	2.82%		5.8%
Vi/Vim		3.83%
Weblogic Workshop		0.87%	0.5%
Forte	1.24%
AnyJ	0.20%
CodeGuide	1.16%
Elixir IDE	1.39%
jEdit	7.25%
不使用IDE			7.6%
未使用Java				15.1%
其它	2.35%	5%	4.3%	10.6%

首先需要指明的是上述的数据并不是当前Java用户使用Java开发环境的准确反映，但我们可以从中了解一个大致的状况。现在的 Java环境可以分为三个集团，第一集团是Eclispe它大约占据1/3的份额，第二集团是 IntelliJ IDEA、NetBeans 和JBuilder占据另外1/3的份额，相互之间旗鼓相当，第三集团是以JDeveloper和WSAD为代表的十几种Java开发环境占据剩下的 1/3份额，但每种开发环境占总份额的比重不超过5%。我们考察Eclipse、intelliJ IDEA、NetBeans 和JBuilder这些主流开发环境，可以发觉它们有一个共同的特点那就是可扩展，尽管在实现手段上各有不同。这就是为什么称现在的Java开发环境为XDEs(eXtended Development Environments)的原因，IDEs已经死亡了4年，专业的开发人员需要了解这个事实，因为XDEs也快死了。

总的讲20年来软件工程的发展变化很小，现在许多为人所熟知的概念和方法都是在20年以前奠定下的基础。尽管Gerald Weinberg等人要求特别关注软件开发中人的因素，但无论是过去的IDEs也好，还是现在的XDEs也罢，它们有一个共同的出发点：仅仅注重提高个人的开发效率。现在的Java开发环境，在如何提高个人开发效率上做了许多工作，比如，增量编译器、组件浏览器、可视化编辑器等，但是我们知道现在的Java开发人员主要开发复杂的N-层Web应用，这需要知道多种编程语言、运行平台以及相关的各种组件和Web服务技术，由于影响因素众多，开发人员很难单独完成全部的工作。一般以Web应用为核心的开发团队常常包括项目经理、测试工程师、网络工程师，架构师，软件工程师和内容编辑等角色，有些项目的人数会达到几十甚至上百人，软件开发已经成为一个集体项目，成员之间的合作与个人英雄同样重要。

由于市场的压力，一个软件企业不仅要提高开发人员个体的工作效率，还要提高整个开发团队以及整个企业的开发效率，但在现有的Java 开发环境XDEs下无法完全做到这些，所以新一代开发环境CDEs (Collaborative Development Environments)就产生。Grady Booch和Alan W. Brown的研究表明一个程序员一天工作时间的分配是这样的：分析占16%  (从 5% 到 40%不等)， 设计占14% (从 1% 到 40%不等)，编程占16%  (从0% 到 60%不等)， 测试占10% ，打电话占 3% ，阅读占7% (电子邮件，文档，月刊和杂志)，参加开发会议占 10% ，无关的会议占 7% 。从这些数据可以发现，开发人员用于交流的时间约占工作时间的1/3，开发人员的相互交流非常重要。可是现有的主流Java开发环境一般仅将分析、设计、编程和测试等工具集成进来，却未包括用于交流的工具，这显然不合理。因此，所谓CDEs就是将用于人与人、人与团队以及团队与团队进行交流的工具集成进来的开发环境，比如，CDEs常具有发送电子邮件、进行及时通讯和屏幕分享等功能，通过实现无损耗过程的交流提高开发团队的开发效率。

现在已经商业化的 CDEs是CodeBeamer Collaborative Development Platform和CodePro AnalytiX，上述两款软件都提供Eclipse的插件，可以与Eclipse集成在一起，使Eclipse升级成为一个CDEs，从而提高Java 开发人员的开发效率，而Eclipse基金会开展的两个开发项目 Stellation和 Koi都是希望Eclipse具有一定的协同功能。此外，GILD (Groupware-enabled Integrated Learning and Development)、Hipikat以及IBM的Jazz也是值得关注的研究项目。大家肯定知道Borland已经宣布开发基于Eclipse 的新版JBuilder-"Peloton"，Peloton就是一个CDEs(Collaborative Development Environments)，当它明年上半年发布时，就意味着Java开发环境进入CDEs时代，现在Java开发环境还处于 XDEs与CDEs交替的阶段。

Java开发环境的未来

在可以看得见的将来，Java的开发环境还会是以CDEs的形式存在。开源组织或开发工具供应商将会努力为软件的开发创建一个绝对光滑的平面 (frictionless surface)，实现无损耗的开发过程，以提高开发效率。为了实现无损耗的开发过程，Java的开发环境将会关注以下几个方面：

• 起步阶段方面
• 协作开发方面
• 维护开发团队有效沟通方面
• 多个任务的时间协调方面
• 相互协商方面
• 资料有效性方面

上述6个方面是最容易出现损耗的地方，如果出现了损耗将会浪费时间和金钱，降低整个团队的开发效率。比如，每个Java开发人员都有这样的经历，当一个新的项目开始时，总要有一个了解的过程，而进入新的开发团队时也需要一个适应过程，这些都叫起步损耗。在起步阶段花费的时间越少，起步损耗就越少，而开发的效率就越高。所以减少6个方面的损耗相应地就是提高了开发效率，这就是CDEs比XDEs开发效率更高的奥秘。未来的Java开发环境也许具有下述功能：

• 及时通讯功能
• 举办网络会议功能
• 集中的信息管理功能
• 应用程序共享功能
• 搜索与查询功能
• 屏幕共享功能
• 任务列表功能
• 文档的流转功能
• 在线投票功能
• 电子公告功能
• 计划与日历功能
• 时间提示功能
• 工作流程安排功能
• 电子邮件功能
• ...
  

但这里必须承认未来Java开发环境是如何具体去实现无损耗的开发，还需要时间给予答案，因为现在所能采用的方法未必是最好的，比如，使用面向文件的 CVS进行协同开发就有需要改进的地方。

总结

罗里罗唆一大堆，归纳起来不过就是：一个目的、三种手段以及一条规律。
一个目的：十年Java开发环境的演变，其目的就是为了提高开发效率。
三种手段：

• 提高集成在Java 开发环境中开发工具的性能和易用性
• 将Java开发环境尽可能的覆盖到整个软件的开发生命周期
• 集成人与人、人与团队以及团队与团队进行交流的工具

一条规律：软件开发环境的发展过程是从CLEs到IDEs再到XDEs最后进入CDEs，这是由Grady Booch总结出来的，套在Java开发环境上也适用。

参考文献

1. Grady Booch and Alan W. Brown, "Collaborative Development Environments",  Advances in Computers 59, Aug. 2003.
2. Li-Te Cheng,Cleidson R. B. de Souza,Susanne Hupfer,John Patterson, Steven Ross, "Building Collaboration into IDEs", ACM Queue vol. 1, no. 9 - December/January 2003-2004
3. J. des Rivie` res,J. Wiegand, "Eclipse: A platform for integrating development tools", IBM System Journal,Volume 43, Number 2, 2004
4.The Java Extension Mechanism.
5. Grady Booch, "History of Development Environments", January 29, 2004