Java这十年 - Java技术本纪 (3)

Java技术本纪

Java虚拟机的  10    年
文/曹晓刚

Java虚拟机的起源与构造
当我们说到“Java”这个词的时候，指的是四个相互关联的概念：Java语言、Java API、Java Class文件格式、Java虚拟机。整个Java体系是基于Java 虚拟机构造的，正因为如此，才能实现Java的安全性和网络移动性。Java并非是第一个采用“虚拟机”概念的体系，但却是第一个得到广泛运用的虚拟机平台。 “虚拟”，是一种隔离物理资源与逻辑资源的手段。Java虚拟机的“虚拟”，则是用来隔离物理机器、底层操作系统与Java语言规范实现的手段。
虽然Java是一种面向对象的语言，我们平时大量使用的，是对象间的多态、组合(Composition)、委派（Delegation）,但当我们讨论虚拟机的时候，我们看见的基本概念却是“栈(Stack)”和“堆(Heap)”。根据冯诺依曼的“存储计算”模型，所有的代码都保存在代码空间中，随着程序计数器指针的变化进行程序的执行、跳转。Java虚拟机中没有寄存器的概念，方法调用是采用“栈”进行的，这是一种安全、简洁的方法。
Java虚拟机通过类装载器支持对类的隔离，这也是Java实现安全性的基础。每个类都具有自己的命名空间，在具有不同安全级别的沙箱中运行，因此不会产生低安全级别的代码来越权访问高级别代码的机会。类装载器的出现是Java虚拟机与大部分用C实现的虚拟机的显著不同之处。
Java虚拟机的另外一个显著特点就是实现了自动的垃圾收集。在往常，写程序的时候要牢记对象之间的关联，在每个程序块中假若申请了对象空间，就必须在出口释放掉，方法调用往往同时也就是对象的边界。而自动垃圾收集带给开发者的最大好处，就是可以非常方便地从整体上把系统的对象组织成一张对象图，只需往这张图中添加对象，维护对象之间的关联，却不需要自己做复杂的清扫工作。正是有了这种思维单纯的对象图的支持，OR Mapping(关系数据库与对象映射）技术在最近得以大行其道，设计模式也更容易被Java群体所接受。

虚拟机的优化
1995年第一代的Java出台之时，其虚拟机执行是依靠“字节码解释器（Byte Code Interceptor）”的，也就是说每条指令都由虚拟机来当场解释执行，这造成速度令人抓狂地缓慢。更有甚者有人开始总结许多的“速度优化经验”，比如说：“尽量把所有的代码都放在较大的方法中执行”与“少用接口”等等，这完全与Java语言的设计目的背道而驰，现在看起来是多么可笑的奇谈怪论，当时却是很多程序员津津乐道的经验之谈。无他，Java本身执行太慢了。Java生命的前十分之三就是如此缓慢地渡过的。
于是，Sun的工程师开始拼命想着提高执行速度。JIT静态编译器的出现是在1996年十月，Sun放出了第一个编译器。JIT编译器在每段代码执行前进行编译，编译的结果为本地静态机器码，执行速度有了质的提高。Symantec公司当时凭借其傲人的JIT编译器，在整个Java界受到热烈的追捧。在其后的1998年，Java 1.2发布的时候，附带了JIT编译器，从此Java的使用者终于可以抛开上面说的那些奇怪的“速度优化经验”了。
JIT静态编译器虽然可以解决一些问题，但是性能仍然和C/C++有很大的差距。对一段程序而言，一名优秀的程序员是如何来改进运行速度的呢？首先，他不会傻到把所有的代码都来优化，他会观察、思考到底哪段代码对整体性能影响最大？然后集中精力来优化这一段代码。按照经验，整个程序 10%-20%的代码，会占据 80%-90%的运行时间。用这种方法，在同样的时间、付出同样程度的努力后，这名优秀的程序员使整个程序的性能得到了很大程度的优化。HotSpot引擎，就是模仿人工的这种方法进行优化的。在程序运行的开始，Java代码仍然解释执行，但HotSpot引擎开始进行采样(Profiling)。根据采样的结果，决定某段程序是占用较多运行时间的，就认为它是“HotSpot”，它也就是目前程序的瓶颈， 引擎开始启动一个单独的线程进行优化。因为不象原始的 JIT编译器那样无差别的编译所有代码，HotSpot引擎可以集中精力来对HotSpot代码进行深度优化，这样这部分代码执行起来更加迅捷。之前的静态编译器只能按照预定的策略进行编译优化，而HotSpot引擎的优化是基于采样的结果的，因此这种方法对所有的应用程序都有效。1999年3月27日，Sun放出了第一个HotSpot引擎。在随后的2000年5月的JDK 1.3中，包含了HotSopt引擎，这也使1.3成了一个具有里程碑意义的发行版本。到这里，Java的十年生命，已经过去了一半。
HotSpot代表的是一种动态编译的技术。对Java这种大量使用委派、组合等面向对象特性的程序来说，动态编译比起静态编译来有显著的优势。比如Method Inlining。方法的调用是一个很耗时的操作，假若可以把方法调用直接内嵌到调用者的代码中，就可以节省大量的时间， 这被称为“Method Inlining”。因为涉及到类的重载，静态优化很难确切知道哪些属性、方法被重载，因此很难对method进行合并，只好在方法内部进行静态编译，假若每个方法都很小，静态优化能起到的作用也就比较小。而动态编译因为可以完全随时掌握类的重载情况，就可以把相关的方法合并进行深度优化。现代的Java程序，特别是在设计模式教育得到普及之后，大量使用类的继承、委派，形成了很多短小的方法，动态编译的优势就更加明显。
自从出现了HotSpot之后，整个Java界为之一振。
最近的五年，就是继续优化的五年。继续进行优化的方法有几条路，一是研究新的采样算法。因为采样关系到不同的优化策略，会对整体性能有比较大的影响。二是研究深度优化的方法。三是研究垃圾收集的算法。垃圾收集会带来程序短暂的停顿，这会带来负面的用户体验。于是，如何提高垃圾收集的效率，减少延迟，出现了五花八门的算法，比如渐进式收集、火车算法等。在多处理器的时候，如何利用多处理器进行并行收集也是研究的一个热点。这方面，BEA的JRocket走在了前面。

现实生活中的虚拟机
最后，让我们来盘点一下目前市面上可见的各个虚拟机。
首先要提到的，毫无疑问是Sun的虚拟机。作为大众心目中的“官方实现”，Sun拥有最大的用户群，并且拥有“兼容基准”的地位，其他虚拟机都必须要考虑和Sun虚拟机的兼容性问题。比如 JRocket就会在某些特殊情况下表现出和Sun不同的特性，可能对程序运行有影响。不过Sun也的确没有让广大用户失望，虽然在早期性能比不上Symantec,后来在1.2 的时候性能又被IBM超越，但Sun一直在努力革新，特别是 1.4.2之后，性能有了长足的进步。虽然JDK 1.5的虚拟机在性能上没有什么提高，但是增强了稳定性，据说修改了8000处bug，真是让人汗流不止。原来我们在1.4.2下面一直在享受这么多bug啊。
其次是老牌劲旅IBM。IBM的JDK在1.3的时代创下了最好的性能记录，从此树立了高端形象。特别是在其WebSphere产品中得到了很好的评价。其JDK也是最早支持64bit的JDK之一。到了现在，IBM JDK在高端仍然是和BEA可以一拼的。
然后是后起之秀，BEA的JRocket。说到BEA突然在JVM领域一夜之间异军突起，多少让人有些瞠目，不过它采取的战略特别简单：自己没有，索性花钱买了在此领域深有研究的JRocket，在前面加上BEA的标志就可以了。JRocket瞄准高端服务器市场，在多处理器环境下有不俗的表现。
除此之外，还有几个开放源代码的JVM值得一提。首先就是大名鼎鼎的JikesRVM。说起其大名，大多数人都知道Jikes编译器是 IBM开发的，效率比同等的javac编译器高得多，很多开发者都使用Jikes编译器来取代javac。而JikesRVM则是IBM开源出来的一整套虚拟机技术，包含了JIT，GC的完整实现，在其网站上也有众多的论文，实在是想要深入研究JVM者的绝佳资源(http://jikesrvm.sourceforge.net)。
Kaffe是一个老牌的JVM,不过现在已经很少听到了。作者撰写此文时，www.kaffe.org网站已经没有响应，也不知道现在的情况如何了。
GNU则有两个计划：GCJ和GNU classpath。GNU classpath是一个底层实现，而GCJ是支持java的预编译器。

结束语
时光流转，轰轰烈烈的Java虚拟机性能争论仿佛还在耳边回响，现在新的争论却已经是“Java的性能是否已经超越C/C++”。Joakim Dahlstedt 是 JRockit 的主要架构设计师之一，他坚持认为，Java绝不是一种速度慢，效率低的语言，JVM 是一个关键的组件，确保了系统的部署与运行和开发一样快速、轻松。特别是在目前开发趋势是采用大量预制的框架时，动态编译有可能比C/C++这样的静态优化获得更好的性能。

 

J2EE五年: 从起源到目的
文/刘天北

起点
在“J2EE”这个缩略语被第一次介绍给世人的时刻，也许没有几个人可以预料出它在日后的奇特历程。那是在1999年6月的JavaOne年会上，时任Sun公司Java企业开发部门主管的Mala Chandra兴奋地预告了Java世界的这位新成员。那些不熟悉背景的听众们，揣摩着她演说中出现的一串串全新术语，表情大概又是惊喜、又是迷惑:一个完整的“多层企业开发架构”、以“容器”和“组件”的形式提供服务、一套“厂商中立的开放技术规范”、对开发者隐藏了不同平台和“中间件”的技术细节、实现了企业级应用间的“无缝集成”等等。在今天的开发者看来，这些似乎都已经是老生常谈，但在当时的场景下，闪动在幻灯片上的每一个口号，都意味着听众们事后又要经历一段困难的学习过程。
幸亏Chandra有一副了不起的口才；这位本科念建筑学的印度裔高层主管，谈起软件架构来也有特强的空间想象力。她清晰地说明了设计J2EE架构的两个初衷：首先，对于厂商，J2EE意味着一套开放标准，加入这个标准，他们的产品就可以运行在各种不同的操作系统和工作环境下，成为一个成熟的企业运算体系中可替换的部件；其次，对于开发者，J2EE是一套现成的解决方案，采用这个方案，企业应用开发中的很多技术难题（包括跨平台移植、事务处理、安全性等等）就会迎刃而解，“信息像一条不间断的河流，经过各种各样的平台和设备，从企业应用系统的这一端流向那一端”。
要想理解这段话在当时的实际效应，我们仍然要把时间指针拨回1999年。除了预备迎接千年虫之外，99年你做了什么？为了回答这个犀利的问题，我翻出6年前的工作记录，发现了自己那时参与的一个项目的规格说明书，它正好能提供一幅“Java企业开发”在1999年的标准照。这是一家日本知名IT厂商的企业信息管理系统，运行在NetScape 3.0 Gold浏览器中的Java Applet界面，通过一个专用的中间层系统与Oracle 8数据库连接。这个中间层已经相当现成、完善，能够提供远程对象调用、事务处理等一系列的底层服务；留给我们的任务只是完成服务器端业务对象代码，以及相应的客户端交互开发。
除了Applet客户端有些特别之外，上述系统与今天常见的J2EE架构很接近；尤其是业务对象编码也由home类、PK（主键）类、entity类等部分构成，很多机制都与EJB如出一辙——只不过这些类并没有继承javax.ejb包的接口，而是采用了专用的API。它与EJB之间的相似不像是偶然的，设计者肯定参照了Sun在1997年底推出的EJB 1.0技术规范。
换言之，在J2EE诞生伊始的语境中，市面上已经存在着很多程度不一的“准J2EE中间件”了。它们主要用于解决三大类问题：事务处理、分布式对象管理和Web请求处理。首先，事务处理管理器（Transaction Processing Monitor）一直是高端企业计算领域的热门产品，著名的应用服务器厂商BEA，正是通过收购事务处理软件Tuxedo进入中间件市场的。另一方面，从90年代初开始，越来越多的人把“N层分布式对象架构” 当成传统的客户端/服务器架构的替代方案。那时刚刚兴起的CORBA技术是推动这一趋势的重要力量（比如说，前面提到的那个由日本厂商自行开发的专用中间层，就采用了CORBA作为基础架构）。最后，Java技术在Web领域中的应用也是当时初露头角的热点。1997年6月，Sun在发布一款“Java Web Server”的同时第一次公布了Servlet API；没想到这项技术副产品（连同1998年问世的JSP）正好迎合了厂商的战略需要。对于上面提到的N层架构来说，HTTP服务是一个非常理想的前端；所以基于Java的Web引擎，也在此时成了企业级Java解决方案的一个必不可少的部分。
Java、Web、事务、分布式对象，这几股开发潮流汇合在一处，形成了当时最热门的产品“应用服务器（Application Server）”或“中间件（Middleware）”。为了给定语“最热门”作个注释，我们可以参照一下BEA公司在1998年收购Web应用服务器厂商Weblogic的成交价：1.92亿美元。而这并不是一桩孤立的收购，NetScape和Sun也以相近的价格买下了另外两家企业Kiva和NetDynamics。而这也正是J2EE规范出台的背景：几乎所有要厂商都推出了、或是正在赶制自己的应用服务器产品，但这个“应用服务器”究竟应该是什么东西，竞争者们又各有表述、莫衷一是。
说到这里，我们才梳理出了J2EE技术规范的第一个版本在1999年12月问世的实际意义。首先，它为Java企业开发提供了一幅清晰的全景，各项分支技术在这个领域中的地位和作用得到了客观、准确的定义。至此大家才对一个Java企业解决方案的构成要素有了基本共识。其次，它使用“容器”和“组件”等概念描绘了Java企业系统的一般架构，明确地划分了中间件厂商和应用开发者的职责所在。最后（但绝非最不重要地），J2EE通过一套公开标准规定了应用服务器产品的具体行为，在执行此标准的厂商产品之间实现了一定程度的可替换性和互操作性。当时的媒体用“B2B开发的默认标准”之类的说法欢呼这项里程碑式的成就——那些撰稿人哪里知道，在J2EE与那个被称为“B2B” 的短命新贵之间，其实并不会有太多故事发生；同样，他们也不会想到，J2EE要想成为一种真正成熟的开发范式，前方还有一段远为艰辛的旅程。

社区的形成
记得Kruglinski在名著《Inside Visual C++》的某个版本中给出了一个Web浏览器的代码例子；在这一节的开头他说到：如果你几年前开发了一个Web浏览器，那肯定会给你带来上千万的收益；但如果你现在才想到开发这个东西——那也就是个C++语言的练习罢了。在今天的程序员眼中，应用服务器似乎也成了价格低廉（如果不是全然免费）的日用消费品。所以，想要理解它们在那几年的大行其道，就非得借助Kruglinski这样的智慧不可。在1999年底，市面上可以找到30种以上自称“Java应用服务器”的产品，可见当时这类软件是网络风险投资的宠儿。但是此时出台的J2EE规范就像是一阵席卷整个产业的劲风，在一夜之间，所有人都有了判断什么是一个“应用服务器”的权威途径。
为了获得一张J2EE竞技场的入场券，各家厂商面临两项考验：首先，要具有能够覆盖J2EE中所有主要技术的产品线。这在当时是一项非常苛刻的要求，在没有开源产品可供参照的情况下，短时间内推出包括EJB容器、Web引擎和JMS中间件的整体解决方案，这决不是随便哪家创业公司都能办到的。完成了若干次成功的并购之后，BEA在这一点上抢占了先机，完整的产品线使它成了人们心目中的首选J2EE平台提供商。其次，要让产品通过Sun的J2EE兼容性测试。要做到这一点同样不易：就连IBM的WebSphere也一时还没达到百分之百的EJB支持。到2000年底为止，共有15家厂商能够提供完整的J2EE解决方案，其中9家（包括Sun本身）实现了“J2EE兼容”，他们中间包括了日后这个领域的主要竞争者。毫无疑问，这是一次非常残酷的行业洗牌，但留在场内的厂商也相应地形成了推动J2EE发展的主体力量。
上面说过，在它的孵化阶段，Sun的J2EE团队主管是女强人Mala Chandra，她本人虽不是工程师出身，但对技术有着很强的感知能力和想象力；J2EE一出台就能够为人们提供一幅完整、直观而不失深邃的图景，此中当然有Chandra本人的大量贡献。在她直接领导下工作的几位工程师，也都是Sun内部非常杰出的人才。无论是制定了JDBC、JMS等规范的Mark Hapner、JavaMail的设计者Bill Shannon，还是EJB的主要设计者Vlada Matena，后来都是业界一言九鼎的技术领袖。这个班子的合作时间并不太长：2000年左右的那个时期正是IT界创业的黄金年月，Chandra很快就和Sun公司Java部门的总裁（也是创造Java的功臣之一）Alan Baratz一起，到一家刚起步的Email中间件公司Zaplet淘金去了；捷克裔的开发天才Matena也离开Sun开办了自己的公司。留下的两个人Hapner和Shannon先后担任了J2EE技术的首席设计师。
多年以后，Hapner回忆起J2EE初创的那个时期，深感如今Sun对Java的左右能力已经大不如前：“现在，Java事实上属于整个技术社区，它的发展有赖全体参与者的推动。”的确，如今Sun已经不太可能重演当年的开拓性功绩，很难再为一个已经成形的领域重绘版图。但正如上文所说，即使是在1999年，J2EE设计者们面对的也不是一张从未着墨的白纸。他们的设计始终要以各大厂商的现有产品为出发点，这也是天才的设计师们做出的设计却远非完美的原因之一：与从头设计一门全新的编程语言不同，J2EE规范从一开始就是各方博弈和妥协的产物。
很容易注意到，J2EE与Java社区的决策机制JCP（Java Community Process）是几乎同步产生的。J2EE下属的各种技术规范，包括1.4版之后的J2EE本身，都作为待决规范议案（JSR，Java Specification Request）被纳入了JCP的议程。这些议案的审议过程很少是一帆风顺的，几乎每一个都要经历18个月以上的拉锯战。在多项技术规范的审议过程中，我们都见到了这样的现象：最初列名审议委员会的某家主要厂商，没能等到该规范通过就已经被收购或倒闭了。与微软在.NET平台上的乾刚独断相比，J2EE发展中的这个“牛步”特征虽说是审慎和民主的表现，但终归不符合软件演化应有的速度。
J2EE社区中的另一股重要力量，当然是种类极为丰富的开放源代码项目。2002年以来，在J2EE领域的各个层面上，几乎所有主流产品都有来自开源项目的替代方案，在其中很多位置上，开源产品反而是胜过商业产品的首选。但请别误解，这里的“开源”并不意味着完全的自动自发，J2EE世界中的开源项目也与Linux或PHP世界颇为不同。在很多非常成功的J2EE开源项目背后，我们都能发现商业机构的推动作用：Apache的Jakarta社区是IBM扶植的结果；实现了开源应用服务器JOnAS的ObjectWeb，则是许多法国IT厂商（包括若干政府部门）合资支持的一个联盟组织……这些有商业背景的开源项目资金雄厚，人员齐整；更重要的是，从投资者到开发者，参与这些项目的很多人都体现了软件工业中难得的非功利心态，因而最终推出的产品质量甚至高于同类型的商业软件。在主流厂商之外，它们是支撑J2EE大厦存在的一组基石。
另一方面，不少开发者也间接地通过自己的开源产品获得了可观的盈利。这些人大多以免费的开源产品为依托，以收费方式提供附加的咨询、方案实施以及技术支持服务。Marc Fleury，开源应用服务器的JBoss创始人，不无矛盾地把自己倡导的这种商业模式称为“职业开源开发”。
无论叫它什么，高端产品的开源化/免费化运动注定要在J2EE产业的发展过程中制造显著的后果。“JBoss的行径恶化了J2EE的商业环境，”这是McNealy先生2002年的著名论断。他的推理过程如下：只有做好商业推广，J2EE产品才能最终击溃邪恶的.NET平台；但开源服务器会降低主流厂商的销售利润；销售利润越低，用于商业推广的预算就越少；因此，整个J2EE阵营都将受损于JBoss。
但在狂热的开源运动支持者看来，以上论证的大前提就是可疑的。“难道只有会做广告的软件才是好软件？MySQL有过多少广告预算”争论的双方都认为对手误解了软件商业模型的实质。究竟谁才掌握了这里的真理呢？也许只有根据J2EE的未来——也就是它的目标和终点（Telos）——才能做出最终的裁决。

技术的离心力
考察事物的演化，通常有两种对立的方法。考古学家（Archaeologist）探究肇始和起源；目的论者（Teleologist）则揭示目的和终点。对于前者，“开端（希腊语Arche）”从根本上决定了此后的发展，参天大树的繁茂都包含在种子最初的萌芽中；而对于后者，“目的（Telos）”才是事物的根本和旨归：谁没见过样态完善的树，谁也就没法弄懂种子到底是怎么回事。
在J2EE五年之后，人们只能交替地用这两种目光审视它的演化历程。它的起源与它的目的、“它从何处来”与“它往何处去” 的问题紧密地交织在一起，谁拾起了其中的一个，谁也就要连同另一个一起回答。
今天的J2EE在多大程度上符合它的初衷？回答这个问题并不涉及对J2EE技术成败的评判，而只是要考察一下：它是否还运行在最初开辟的那个空间之中。在事务处理、对象分布化和Web请求处理这三个方面中，也许J2EE对事务和Web保持了一贯的忠诚。我们记得Fleury喜欢重复的一个信条:“He who owns the transactional Web owns the Web（谁掌握了带事务处理的Web，谁就掌握了Web）”Web接口是今天大部分J2EE应用暴露的唯一接口；而虽然事务处理的常用方法已经有了很大改变（借助AOP机制，很多非EJB架构的系统也自如地实现了声明式的事务处理），但对事务的重视当然仍将是J2EE开发中的要素之一。
换言之，在5年的演化中，J2EE发生的最大变化可能就在于它放弃了对“分布式对象模型”的强调。EJB2.0引入的本地接口使得Web层与EJB层可以运行在同一个Java虚拟机中，从而使Web容器与EJB容器的物理分离部署变成一种昂贵的冗余；J2EE 1.4以后版本支持的Web Services兼容性，使得客户端可以通过粗粒度的Web接口调用远程服务——这两次变化事实上都是在论证“分布式对象架构”的无用性。人们发现，同一系统的各个分层最好采用细粒度接口调用，并且运行在同一个进程中；之所以划分不同的层次，与其说是为了实现物理上的可扩展性，不如说是设计美学上的考虑。而对于异质系统之间的调用，则应该尽量选用异步的、粗粒度的服务接口（所以Web Services成为了非常理想的选择）。换句话说，传统上的“分布式对象架构”，现在看来似乎只适合于银行远程支付等要求极为苛刻的应用场景，而绝不是所有J2EE应用都该考虑的标准方案。
前面描述的离心现象毕竟还遵循了J2EE发展的内在逻辑，说到底，EJB的革新和Web Services的引入更多地是主流厂商倡导的结果。但在近年来，还有一股更强劲的离心潮流在深刻地影响着J2EE的演进，它肇始于上文提到的开源软件运动。最初它只在Rickard Oberg的动态代理RMI设计与JBoss服务器的微内核架构中显露过邪恶的一角，但是两三年来，经过多个项目、各种技术杂志/论坛/Blog的折射和放大，它已经形成了一个名为“轻量级容器架构”的完整解决方案，并暴露出完全取代传统EJB架构的终极野心。按照这一运动信徒们的说法，J2EE的发展史上只出现过一个错误——不幸的是，这个错误名叫EJB。与EJB提供的重量级架构不同，借助AOP和IoC机制，轻量级容器能够最大程度地降低代码对于专用接口的依赖性，以简短、轻便、专注、可移植的方式实现业务对象。从“轻量级容器架构”这个词被发明出来的那一刻起，人们对J2EE远景的考虑就发生了根本性的分裂：Sun和大部分主流厂商更多地关注于“Web Services”和“快速开发工具”这些利润增长点，而一部分离经叛道的独立专家和开发者则认为，如果不把轻量级容器纳入规划，J2EE的发展蓝图就注定无足称道。其实，双方争执的关键是传统意义上的“应用服务器”的存亡——如果所有企业级服务都可以通过AOP机制提供给普通Java对象，如果管理业务对象生命周期的可以是一个最微不足道的“微内核”，那么深盔重铠的应用服务器还有什么存在理由？而如果失去了应用服务器的这个产品类型，那些靠这项销售起家的厂商又将何以自处？
正是在这里，两个阵营之间存在着最深刻的利益分歧；而这场争执的结局当然也将决定J2EE（乃至Java企业开发）的最终走向。或许两年之后，我们将从纷争中胜利者一方的角度重述J2EE的整部历史——或许两年之后的J2EE本身也将随着纷争的解决而成为历史。但让我们换个乐观的口吻：问世五年，J2EE的历史仍在持续的创生之中；此时善待这树种的人，也必在今后的树荫下获得它的祝福。

 

Java十年有成——谈J2ME的发展历史
文/王森

Java本来就是为了嵌入式系统而生
1990年12月，Sun内部由James Gosling、Patrick Naughton以及Mike Sheridan成立了一个叫做Green Team的小组。Green Team小组的主要目标，是要发展一种新架构，而这种架构必须能够在消费性电子产品作业平台上运行，现在我们普遍认识的PDA、手机或是信息家电(IA)，都是属于这种架构的目标平台。接着，Green Team在1992年的9月3号，发表了一款由Java 技术之父 James Gosling所领军研发，名叫Star Seven(*7)的机器，研发出一部交互式的掌上型家用娱乐装置，可透过使用动画触碰式屏幕的使用者接口来控制其它电子设备。
经过了13年的时间，现在我们检视J2ME的发展历史，我们可以发现，虽然在1999年，Java被切割成J2SE、J2ME、J2EE，所以有了J2ME这个名词的出现。但是Java并非1999年开始才开始发展嵌入式系统上的应用。其实，Java本来就是为了嵌入式系统而发展的一种架构。即使目前大家多半将Java的应用聚焦于企业上的J2EE应用。但是严格来说，J2ME才是Java真正“回归本心”的领域。

半路杀出的Personal Java
Personal Java是正规Java版本的一个分支，其目的在于能够让PDA或高阶手机执行Java程序，目前在Windows Mobile或Symbian OS(仅限采用UIQ或Nokia Series 80的行动电话)平台上都可以开发Personal Java应用程序。
虽然从Java 1.0发表之后，Java就被广泛地使用在桌上型应用程序以及Applet的开发上，但是，从Java 1.1开始，Java又回到了它一开始的老路-也就是嵌入式系统方面的应用，在当时Sun Microsystems发表了Embedded Java与Personal Java（也有人简称为PJava）这两项规格。Personal Java的规格是从Java 1.1之中所分支出来，因此Personal Java的规格是根据Java 1.1的规格而制定的，但是并非Java 1.1的全部规格都包含进来，所以Personal Java只能算是Java 1.1平台的子集合。
Personal Java特别适合用在具有丰富图形显示能力的消费性电子产品上面，于是我们可以发现Sun Microsystems网站上对于Personal Java的参考实作是建立在Windows Mobile产品(过去叫做Pocket PC)上头的。
在1999年，一般PDA或手机的能力，离Personal Java所需要的硬件条件仍有很大的一段差距，因此Personal Java并不是一个很成功的产品。因此Sun Microsystems在此时将Java区分成J2SE、J2EE、J2ME这三块，希望可以重新塑造整个架构，尤其是J2ME，希望Java可以在嵌入式系统的领域有所发展。

J2ME从何而来?
谈到J2ME，大家就会联想到KVM这个名词， KVM的设计者Antero Taivalsaari，最早在Sun Microsystems参与Spotless Project，这个项目才是J2ME的最早起源。由于Antero Taivalsaari曾经在世界知名电信设备制造商工作，所以他有了在手机上开发JVM的概念，后来得到公司支持，就有了各位所知的KVM(K Virtual Machine)。
最早应用KVM的产品，就是一个可以在Palm OS上执行的KJava。KJava并不算是一个正式产品，只能算是一个概念测试产品。开发人员会开发名为Spotlet的应用程序，透过工具和KVM的辅助，应用程序就可以在PDA上执行。虽然KJava早已成为过去式，但是仍有电信厂商使用这个名词，作为手机上Java平台的名称，不过，已经不是真正的KJava了。有了KJava的发展经验，Sun着手设计J2ME的架构，让J2ME可以应付未来嵌入式系统的发展。

J2ME整体架构
J2ME最基本的规范制定在JSR-68(Java规格编号第68号)，在此规格里头定义了J2ME的技术架构。根据此规范，J2ME由三种类型的规范堆栈而成，分别是Configuration、Profile以及Optional Packages。这三种类型的规范定义由其它的规范所定义。
在最底层的Configuration规范，定义了硬件所必须具备的能力，比方说硬件至少具备多少ROM、RAM，CPU的频率最少应该是多少，连接网络时频宽至少要多快。Configuration规格之中定义了一组低阶的API，这代表Java至少必须提供的低阶功能，这组低阶的API就是核心类别函数库的子集合。
在Configuration之上的规范称为Profile。Profile针对各种不同机器的特性定义了高阶的API，这些高阶的API通常都是与其它平台不相关的扩充类别函数库。这些高阶API决定了该种机器上Java程序的撰写方法。比方说行动通讯装置(手机、PDA等)这类型装置上Java程序的撰写方式，以及能够调用的API，都定义在MIDP(Mobile Information Device Profile)之中。
就算是同类型的装置，有些功能也不一定具备(有些厂商的机器可能有，有些厂商的机器可能没有，例如手机上的照相机、和弦铃声等)，这些功能就定义在“厂商选择性实现套件(Optional Package)”之中，比方说，有的厂商会提供简单的数据库管理系统(DBMS)在该装置上，那么他们就会实现JDBC Optional Package。不提供数据库管理系统的厂商就不需要实现JDBC Optional Package。所以称作厂商选择性实现套件。
所谓的厂商选择性实现套件，意思是说，这是一组和其它规格(或API)没有任何相依性的类别函数库，如果厂商愿意提供这样的功能给程序设计师(通常是因为硬件具有充分的能力可以完成规格之中所制定的功能)，就会将这组类别函数库实现出来，程序设计师也可以利用这些功能开发出功能更多的应用程序。

MIDP工业标准
虽然J2ME架构完整，但是目前的发展，除了Personal Profile之外，最大的应用在于架构在CLDC之上的MIDP。目前所有标示可以支持Java的手机，所支持的都是MIDP，几乎所有的无线通讯厂商皆采用MIDP作为其开发程序的标准。
在MIDP 1.0的时代，由于规格上本身的功能不足，使得许多厂商不得不加入自己专属的API，例如震动、背光、声音等扩充功能(例如:Nokia UI API)，以弥补MIDP平台的不足。
到了MIDP 2.0，增加了许多众所期盼的功能，但是，即使规格更清楚了，即使很多新功能都已经由JCP制定成标准的Optional Packages，这些问题依然无解。市面上的MIDP平台仍然处于混乱状态。开发者必须在执行时期侦测各种专属API和Optional Package的存在，这会增加多余的程序代码。平台的混乱会造成在某个装置上可以顺利安装及执行，而到了其它装置时，有可能无法执行，甚至有可能连安装都有问题，所以开发者通常要开发好几种版本的MIDP应用程序供各种厂牌、各种型号的装置使用。
为了解决上述问题，进一步提高MIDP应用程序的可移植性，Sun Microsystems以MIDP 2.0规格为核心，设计了JTWI规格。未来的无线通讯平台，将不会只有符合MIDP 2.0规格，而是必须要符合JTWI规格。这将是J2ME软件在可移植性上的一大突破。JTWI(Java Technology for Wireless Industry)是一个统合性的规格，其目的是为了确保MIDP软件的可移植性。所以JTWI规格除了规范无线通讯平台(特别是手机)所必须支持的J2ME标准之外，也对既有规格中模糊不清的地方与以加强。所以新款的手机为了加强移植性，都会支持JTWI标准。JTWI只是一个统合性的规范，并没有制定任何新功能，目的只是要统一当前平台混乱的现象，让J2ME应用程序更具可移植性。JTWI主要分成几个部分:
1 .规定平台必须支持的API。
2 .统一的应用程序执行环境。
3 .既有规格的理清与加强。
在规定平台必须支持的API的部分，JTWI规定至少必须支持CLDC 1.0、MIDP 2.0以及WMA 1.1:

所以，只要厂商宣称支持JTWI平台，那么代表一定支持CLDC 1.0、MIDP 2.0以及WMA 1.1规格之中的所有功能。另外，厂商可以根据装置本身的能力，将CLDC 1.0提升成CLDC 1.1，可以加入MMAPI 1.1。因此实际上JTWI平台会有一下几种组合方式:
其中，CLDC 1.1 + MIDP 2.0 + WMA 1.1 + MMAPI 1.1是最完整、功能最强平台。
在统一应用程序执行环境方面，过去让J2ME应用程序开发者最为头大的问题有以下几项:
● 应用程序的大小可以多大? 
● 执行时期的内存有多少可以使用?
● 有多少内存空间可以作为永久储存之用?
由于规范中对于J2ME应用程序本身的大小和执行环境没有很详细地规范，使得每家厂商都有自己的规范，比方说Nokia限制应用程序最大只能30 KB，Motorola则可以支持50 KB以上的应用程序。这些规范都严重地困扰着开发人员。这些问题在JTWI之中都获得改善。
JTWI定义了应用程序的标准大小(Standard-size Application)。JTWI规定，可以执行J2ME应用程序的行动通讯装置，至少可以容许大小为64 KB以上的程序主体(JAR文件)、5 KB以上的应用程序描述文件(JAD文件)、以及30 KB以上的永续储存空间、执行时期的内存(Heap Memory)为256 KB。上述大小只是底线，厂商可以视装置的实际能力支持更大的内存空间。标准应用程序大小(Standard-size Application)将成为一个计算用的单位，举例来说，厂商会说这个装置可以安装20个标准应用程序，开发者所撰写的程序可以说这个程序需要占掉3个标准应用程序的空间。
至于对既有规格的理清与加强的部分，我们将在往后章节一一说明。最重要的一点是，JTWI规定，该装置所支持的任何媒体格式(例如图片、声音、影像等)都应该能够使用HTTP 1.1获取，也就是说，存取这些媒体时所使用的URL都必须能够接受http作为存取的通讯协议。

 

Java开发环境的过去、现在和将来
文/EclipseCN

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)就出现了。Java的出现尽管只有十年，但其开发环境也大至经历了从CLEs到IDEs再到XDEs这三个阶段，现在即将进入CDEs阶段。在上述Java开发环境发展过程中，有许多值得我们大家关注的地方。

Java开发环境的历史回顾
纵观过去十年Java开发环境的发展，大致可以粗略的划分为如下几个阶段:
●  1995，命令行开发环境CLEs
●  1996-2000，集成开发环境IDEs 
●  2001-2004，扩展开发环境XDEs 
●  2005至今，协同开发环境CDEs 
1995年，不平凡的一年，这一年Java 获得了成功。可令人尴尬的是在1995年并没有一个令人满意的Java开发环境，开发人员在进行Java编程时，大多使用文本编辑器编辑源程序，然后再使用命令行的方式进行编译处理。那时的Java开发环境还处于CLEs时代，开发效率非常低，这预示着在Java开发工具上会有一番激烈的竞争。
有人称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签约时，也同时签下了监狱里的一个单元。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。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当中开发工具的性能和易用性，另一方面是将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开发人员的工作实际并将这些工作进行了优化。由于减掉了一些可有可无的工具，所以价格上相对合理公道。当年IntelliJ IDEA击败JBuilder成为最受Java开发人员欢迎的Java开发环境，不过2002年随着JBuilder将大而全的功力再提升一步，将UML建模工具、JUnit测试框架以及Apache Struts等开发工具集成进来，大而全的发展方向又一次受到Java开发人员追捧。最全还是最好似乎使Java开发人员在选择Java开发环境时处于两难状况，但实际上当Eclipse 1.0发布时，这个问题已经得到了初步的解决，最好和最全是可以兼顾的。
Eclipse的出现不是从天上掉下来的，也不是某个天才拍脑袋想出来的，它是一群软件精英们集体智慧的结果。早在1998年IBM就打算开发新一代的工具平台以便将它现有的各种开发工具统一起来，并减少开发各种工具时重复的劳动，同时希望在新的平台上建立新的Java开发环境。经过一段时间的准备， IBM开始建立起一个开发团队，人员构成主要来自VisualAge for Java Micro Edition和VisualAge for Java两个项目的开发人员，选择的标准是过去10年至少开发过5到6个IDE。此外，IBM还联合了9家公司共同成立了一个开源组织Eclipse基金会，将Eclipse提供给开发人员使用，并在开源社区的帮助下进一步完善Eclipse本身。Eclipse在最初设计时，插件模型是静态的，不能实现插件的即插即用功能，即便是大受欢迎的Eclipse 2.1也还是静态的。所以到2004年发布Eclipse 3.0时，Eclipse进行了重大改进，采用OSGi的插件模型，初步实现了插件的即插即用功能，至此一个完美的、可扩展的开发环境展现在Java开发者面前，这时Java开发人员已经达到300万。

Java开发环境的现状
2004年Eclipse 3.0的发布极大刺激了Eclipse用户的增长，经过一年以后，Java开发人员现在使用Java开发环境的状况是如何的呢？看了下面的表格里的数据也许可以了解一个大致的状况。
首先需要指明的是上述的数据并不是当前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也快死了。
由于市场的压力，一个软件企业不仅要提高开发人员个体的工作效率，还要提高整个开发团队以及整个企业的开发效率，但在现有的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。大家肯定知道Borland已经宣布开发基于Eclipse的新版JBuilder-“Peloton”，Peloton就是一个CDEs(Collaborative Development Environments)，当它明年上半年发布时，就意味着Java开发环境进入CDEs时代，现在Java开发环境还处于XDEs与CDEs交替的阶段。

Java开发环境的未来
在可以看得见的将来，Java的开发环境还会是以CDEs的形式存在。开源组织或开发工具供应商将会努力为软件的开发创建一个绝对光滑的平面 (Frictionless Surface)，实现无损耗的开发过程，以提高开发效率。为了实现无损耗的开发过程，Java的开发环境将会关注以下几个方面:
●  起步阶段方面 
●  协作开发方面 
●  维护开发团队有效沟通方面 
●  多个任务的时间协调方面 
●  相互协商方面 
●  资料有效性方面 
但这里必须承认未来Java开发环境是如何具体去实现无损耗的开发，还需要时间给与答案，因为现在所能采用的方法未必是最好的，比如，使用面向文件的 CVS进行协同开发就有需要改进的地方。

总结
罗里罗唆一大堆，归纳起来不过就是:一个目的、三种手段以及一条规律。
一个目的:十年Java开发环境的演变，其目的就是为了提高开发效率。
三种手段:
●  提高集成在Java开发环境中开发工具的性能和易用性 
●  将Java开发环境尽可能的覆盖到整个软件的开发生命周期 
●  集成人与人、人与团队以及团对于团队进行交流的工具 
一条规律:软件开发环境的发展过程是从CLEs到IDEs再到XDEs最后进入CDEs，这是由Grady Booch总结出来的，套在Java开发环境上也适用。

参考文献
◇ Grady Booch and Alan W. Brown, "Collaborative Development Environments",  Advances in Computers 59, Aug. 2003.
◇ 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
◇ J. des Rivie` res,J. Wiegand, "Eclipse: A platform for integrating development tools", IBM System Journal,Volume 43, Number 2, 2004
◇ The Java Extension Mechanism.
◇ Grady Booch, "History of Development Environments", January 29, 20

 

J2SE发展演变史
文/Matirx Java社区　杨洪波　王志舜

J2SE:怀胎
Java的历史可以追溯到1991年4月，Sun公司的James Gosling领导的绿色计划(Green Project)开始着力发展一种分布式系统结构，使其能够在各种消费性电子产品上运行，他们使用了C/C++/Oak语言。由于多种原因，绿色计划逐渐陷于停滞状态。
直至 1994年下半年，由于Internet的迅猛发展和环球信息网的快速增长，第一个全球信息网络浏览器Mosaic诞生了；此时，工业界对适合在网络异构环境下使用的语言有一种非常急迫的需求;Games Gosling决定改变绿色计划的发展方向，他们对Oak进行了小规模的改造，就这样，Java在1995年的3月23日诞生了！Java的诞生标志着互联网时代的开始，它能够被应用在全球信息网络的平台上编写互动性及强的Applet程序，而1995年的Applet无疑能给人们无穷的视觉和脑力震荡。
但没有相应的开发库而只靠Java语言来进行开发肯定是困难重重，所以Sun公司在1996年的1月23日发布了JDK 1.0来帮助开发人员的开发。JDK包括两大部分:运行环境和开发工具。紧跟着，Sun公司在1997年2月18日发布了JDK 1.1。JDK1.1相对于旧版本最大的改进，是推出了JIT(Just-In-Time)编译器，另外一个改进是AWT 1.1。
在JDK 1.1时代，Java平台分为PersonalJava与EmbeddedJava，前者比较适用于运算资源和内存丰富的设备，而资源有限者适用于后者。这样的分类明显不符合时代发展的潮流，所以，Java平台处处蕴藏着新的翻天覆地的革命……

J2SE1.2:诞生
JDK 1.2在1998年12月4日的隆重发布，标志着Java2平台的诞生。Java 2的J2SE 1.2时代是一个大变革时代，它进行了如下的三大革命:

● 市场推广革命
Sun公司在Java 1.2版以后将JDK 1.2改名为J2SDK，将Java改名为Java 2。在1999年Sun公司还将Java 2平台分为三大块:J2SE，J2EE，J2ME。这次市场推广革命顺应了网络急速发展的潮流，对Java 2平台的发展起到了很好的催化剂的作用。

● API供应标准革命
而随着供应商的不同，Java的API分为三大类:
Java Core API:由Sun公司制定的基本的API，所有的Java平台都应该提供。
Java Optional API:由Sun公司制定的扩充API，Java平台可以有选择地提供。
特殊API:由特殊厂商或者组织提供的API。

● API制定过程的革命
如果你有需求不能通过遵循标准的API来实现,可以向JCP提出制定新的API的请求,经过审核,你的请求可能被通过或者驳回;如果是被通过,则开始进入制定该API的程序。
J2SE 1.2时代进行的这些革命形成的制度一直沿用到现在,对Java技术的发展形成了深远的影响。
除了上述的三大革命，Java 2还支持并新增了许多新特性，最受追捧的当属Swing库。Swing是轻量级的API，它不但有各式各样先进的组件，而且连组件风格都可抽换。Swing出现之后，大家很快地就不太使用AWT了。Java 2还废弃了一些API，最重要的莫过于Thread类中对suspend(),resume()和stop()等方法的废弃。由于JDK 1.1的集合类库中的Vector类和HashTable类都考虑了同步，在平常的使用中影响效率，所以Java 2专门添加了对应的非同步类，并完善了集合类库。

J2SE1.3:拓广
Java 2平台推出后，得到了市场的强烈反响，所以，在2000年5月8日推出的J2SE 1.3对J2SE 1.2的改进，主要是对各种已有API的加强和对新API的拓展。
数字运算:加入了java.lang.StrictMath,方便我们的一般的数字运算。
新的Timer API:相信大家对其中的java.util.Timer和java.util.TimerTask一定不陌生。
Collections包:加入了一些新的API，方便我们的使用。
虚拟机停止钩子:J2SE 1.3还加入了一个强大的功能，那就是虚拟机停止钩子(Virtual Machine Shutdown Hooks)，这个功能使得我们能够在虚拟机停止时完成我们自己的操作，比如关闭网络连接或者保存会话状态或者清除临时文件等等。
DNS服务:在JNDI接口方面，加入了一个DNS服务的实现。
Jini实现:J2SE 1.3包含了一个Jini实现，这使得我们可以方便地把诸如打印机、摄像机和磁盘驱动设备插入现有网络中，并且能自动搜索已在网上的设备可以提供的服务并享用这些服务。
XML支持：由于计算机网络和XML技术的快速发展， J2SE 1.3在Optional API中引入了Java API for XML包。
HotSpot虚拟机:J2SE 1.3引入了HotSpot虚拟机。在Solaris版的JDK 1.3中，已经不支持传统的虚拟机，而Windows版的JDK 1.3同时支持传统虚拟机和HotSpot虚拟机。
从上面的分析可以看出，J2SE 1.3主要是对J2SE 1.2查漏补缺和拓展新的API。从应用领域方面考虑，J2SE 1.3已经涵盖了数据库、WEB、多媒体、网络、电话、影像、加解密、图形等等大部分的信息技术领域。
在这个时期Java 2还有一个重要活动就是推出SCSL(Sun社区源代码许可)许可协议。Sun公司开放源代码项目的“女1号”Danese Cooper在1999年加入公司，负责Sun（包括Java）和开放源代码社区之间的协调工作。Sun一直尽可能在赢利和开放源代码之间寻求更好的平衡。
Java的大行其道引起了Microsoft的警惕并直接导致了.Net的产生，这同时也宣布了Java作为独一无二的Internet平台地位的结束。这两个对手在较量中相互学习，现在在技术架构上的目标上已趋相同。

J2SE 1.4:快速
J2SE 1.4平台的推出发生在2002年2月13日，由于此前在Java平台和.NET平台间发生了规模浩大的孰优孰劣的论战，而论战中，Java平台最大的缺点就是性能问题，所以J2SE 1.4平台把性能的改善放在了最重要的位置。
HotSpot虚拟机:HotSpot虚拟机能够很大程度上提高性能，所以J2SE 1.4已经不支持传统的虚拟机。现在，启动应用程序应该通过-client或者-server选项来启动。 
锁机制:由于旧版的HotSpot虚拟机的锁机制会导制严重的性能和功能问题，J2SE 1.4已经改写了该锁机制。
安全API:JCE、JSSE和JAAS这三大安全API从optional API移到了core API中。这样，J2SE 1.4的安全域(SecureRandom)实现可以利用操作系统提供的安全机制，以便缩短应用程序的启动时间。
RandomAccess标记接口:加入了RandomAccess标记接口，如果一个List实现了该接口，则表示它支持快速的随机访问，这样可以提高List访问的速度。
LinkedHashMap:加入了LinkedHashMap，这是一个插入排序的Map实现，但它的运行速度和HashMap一样快。
反射:很多产品中都要使用反射(Reflection)机制，但大家知道，反射是相当耗时的，所以，J2SE 1.4中重写了java.lang.reflect.Field、java.lang.reflect.Method.invoke()、java.lang.reflect.Constructor.newInstance()和Class.newInstance()等方法，使得我们利用反射也能写出高性能的应用程序。
64位计算:J2SE 1.4支持64位计算。
新的I/O API:J2SE 1.4在API层面最大的变动，就是它更新了原有的java.io包，以及加入了一组更有效率更多功能的New I/O API。
断言和日志处理:J2SE 1.4版本在Java语言层面上加入了断言（assert关键字），在API层面上加入日志处理API，这些为程序的调试提供了强有力的支持。
从上面的分析可以看出，Java 2平台在经过数年的发展后，已经比较成熟稳定，J2SE 1.4主要是对平台的性能进行较多的考虑和修改。在分布式程序方面，1.4版比1.3版的运行效率提高了一半以上；而在客户端程序方面，1.4版比1.3版的效率提高了1/3。
J2SE 1.4版是J2SE第一个参与了 Java共同体过程(JCP)的J2SE版本。 像Borland、Compaq、Fujitsu、 SAS、 Symbian、 IBM这样的公司，和Sun一起定义并发展了J2SE 1.4规范。在开放、良好的文档编撰与管理的过程中，形成了一个高质量的、代表了Java共同体的多样性的规范。

J2SE5.0:易用
在2004年十月J2SE 5.0发布的时候，Sun公司这样解释这次版本名称不是J2SE 1.5而是J2SE 5.0的原因：“从Java诞生至今已有9年时间，而从有J2SE算起也有5个年头了；在这样的背境下，将该版本号从1.5改为5.0可以更好的反映出新版的J2SE的成熟度、稳定性、可伸缩性、安全性。”
J2SE的这次变更之重大和意义之深远，的确也值得我们为之把版本号变换到J2SE 5.0。我们再看看Sun公司网站对J2SE 5.0的features描述:“通过增强Java平台的力量，允许开发者更容易地使用，Java编程语言的这些改进将吸引大量各种Java开发者”，这是“Java技术发展历程的一个重要里程碑” 。从这个描述我们可以看出，J2SE 5.0最大的目标是通过提供易用性而吸引各种开发者(当然包括以前的C/C++开发者) ，而它对以前版本的修改并不仅仅是API的升级，而且包括对Java语言层面的改进，被誉为是”自Java问世以来的最大一次语言标准变化”。
访问环境变量:最初的Java语言有一个访问环境变量的方法System.getenv()，但因为Java宣称的”Write Once,Run AnyWhere”特性，所以在JDK 1.0中去掉了这个能够访问平台专有信息的方法。在J2SE 5.0中，它又来了，并有所扩充。由此可见J2SE 5.0对编程方便性的重视程度。
泛型:J2SE 5.0提供了强大的泛型机制，让程序员可以减少代码重复，这个变化应该可以吸引小部分的C#开发人员吧。
增强的for循环:为了克服普通for循环的代码臃肿特点，J2SE 5.0提供了增强的for循环，我们现在可以这样写一个for循环:

public void printAll(Collection coll)
{
 for(String str : coll)
 {
  System.out.println(str);
 }
}

怎么样？是不是简单了很多？
自动的装箱/拆箱:
可变参数数目J2SE 5.0开始支持Varargs(不固定自变量个数)，J2SE 5.0中还加入了以前抛弃的枚举和C风格的格式化输出，这应该是为了吸引以前的C开发者吧。毕竟,在C开发中枚举和格式化输出用的是太多了。
并发 J2SE 5.0中加入了java.util.concurrent包，并向集合框架中加入了Queue接口，J2SE 5.0还为各种集合提供了并发情况下的实现。
Properties类增强 由于XML的普及性应用，J2SE 5.0为java.util.Properties类加入了从XML文件中装载属性和把属性值存储到XML文件中的方法。
Annotation功能J2SE 5.0提供了注解(annotation)/元数据（metadata）功能，相信以后的大部分应用产品都将充分利用它的注解而实现产品的各种特性。
其它J2SE 5.0还在多线程（并发机制）、安全、国际化、UI等方面进行了大规模的变更，使得我们能够更方便地进行Java开发。
其实，上面的这些变更，并不是我们程序员非要不可的内容。我们完全可以通过自己的办法来达到这些变更实现的功能。但J2SE 5.0的目标就是让我们程序员能够更加方便地进行开发，所以，我们在基于J2SE 5.0开发时，应该能够明显的体会到它的易用性。

展望
时至今日，J2SE已经发展为一个覆盖面广、效率高、易用性强的技术平台(见如下的J2SE API体系结构图)，但Java并没有停止前进的脚步。Mustang版本的J2SE正在紧锣密鼓的开发当中，按以前的惯例，每两年会发布一个全新的J2SE版本，所以Mustang开发版对应的J2SE 6.0发布版将在2006年完成。
2005年5月23日是Java技术十周年庆典日，在这十年的发展中，Java平台吸引了四百万开发者，在网络计算遍及全球的今天，更是有17.5亿台设备使用了Java技术。作为Java技术的基础，J2SE的功绩不可掩没，我们期望J2SE伴随Java平台一路走好！

MATRIX社区介绍:
Matrix，面向Java爱好者的非赢利性组织。成立以来，Matrix一直不遗余力地为推动中国Java技术和开源软件的进步和发展而努力，发布了Jasmin反编译器，Jmatrix全站系统等开源产品。加入Matrix，与Java共舞（www.matrix.org.cn）

 

中国企业走近JCP
文/黄海波
对Java开发人员，JCP（Java Community Process）这个名词并不陌生。但对国内大部分Java开发人员来说，JCP更多的是一个符号，一个国际Java开发社区的象征。而对JCP这个组织的来源、组成、运作模式以及JCP对中国软件产业，甚至是我们自身工作事业的影响可能不甚了了。由于历史原因、文化语言的差异，国内Java厂商一直未能对JCP引起足够重视，从而导致国内的软件厂商无法参与到JCP的行业标准的制定过程中去，结果就使我们只能跟随制定好的标准，而不能影响标准向着有利于国内软件产业的方向发展。

跟随的劣势是很明显的，以万众期待的下一代Java持久化标准EJB 3为例。EJB 3规范目前仍在早期规范阶段，预计要到２００６年中期才能完成最终版本，但EJB 3专家组中的Java厂商都已经根据讨论的初步意见开始了产品开发，有些甚至开始发布预览版本。而国内的J2EE厂商却可能要等到EJB 3的最终版才可以着手进行研究和开发（根据早期规范不可靠，变动通常很大），差距自然巨大。在其他诸如如商业智能、工作流、数据挖掘等领域都存在类似情况。

可喜的是国内软件业的Java行业组织和管理部门都已经认识到，继续徘徊在JCP的门外不利于国内Java产业的生存和发展，也和国内庞大的软件市场不相符合。在许许多多有志之士（很多是笔者的前辈，他们为国内软件业发展默默努力，实在让人钦佩）的共同努力下，JCP的中国分支也即将成立。而作为第一个尝试，中国的Java应用体验认证实验室在国家应用软件产品质量监督检验中心、Sun计算机系统（中国）有限公司、中国软件行业协会中间件分会、北京软件与信息服务业促进中心四单位共同努力下在北京成立，为中国的Java软件厂商在国内进行软件的JCP认证和兼容测试。

可以预见，在不久的将来，越来越多的中国Java厂商将能走进JCP，发挥自己的智慧，成为能影响Java产业的一支重要力量。