2010年10月29日

O'Reilly Java系列书籍建议阅读顺序

转自:http://blog.csdn.net/beseanlo/archive/2009/09/11/4543885.aspx

Learning Java the O'Reilly's Way (Part I)

Java 技术可以说是越来越重要了,不但可以用在计算机上,甚至连电视等家电用品,行动电话、个人数字助理(PDA)等电子产品,以及智能卡都可以透过 Java 的技术来为人们创造更便利的生活。许多人因此对 Java 感兴趣,想好好学习 Java。

因为讲授 Java 课程的关系,这几年来,不少人问我:怎样才能学好 Java,我给他们的建议很简单 ---『多读 Java 的好书,可以有系统又轻易地获得许多高手的经验』。其实,我说的也是我自己的经验。

『那么,要看什么书呢?』我知道你会这么问。毕竟书店里 Java 的书琳琅满目、怎样从其中选出一本最适合自己的好书,绝对不是一件容易的事。在建议您看什么 Java 书籍之前,让我先为大家做一些简单的分析比较。我认为,Java 原文书可以概略地分成两种:

「主题广泛」型:这类的书经常上千页,厚厚的一本,里面什么主题都有。
「主题专一」型:这类的书通常薄薄的一本,少于五百页,内容只专注在某特定主题。
「主题广泛」型的书,优点是可以让你一次学会很多名词和大概的观念,可是什么都只是浅谈即止,不够深入。 不都说「样样通、样样松」么!还真是有道理。

「主题专一」型的书就不一样了,内容只设定在一个主题,此主题不相关的内容一概不谈(或者只是概略地一提)。 这两类的书各有优缺点,选择哪一种端看您的需求而定。不过,我自己偏好「主题专一」的书,原因是这类的书有下面的好处:

内容深入:你真的相信「21 Days」就可以学通 Java?(我还看过一本书更夸张的,书名上有耸动的「24 Hours」字样。)如果这样的话,Java大师就满街跑了。多读一些 深入的内容,你才有可能超越别人。你可能认为:『我不过是刚入门的初学者,需要知道 Java 广泛的知识,而非深入的知识,所以看「主题广泛」型的 Java书有何不可?』 唔!话说得没错,但我认为这些简介性的知识在许多地方都可轻易取得(特别是在http://www.javasoft.com/),实在不需要去买一本 一千多页的原文书来 K, 现在的原文书也挺贵的,钱可要花在刀口上。

主题属性适合:如果只想学 Java 的网络设计,你当然不会去买一本大堆头的书,其中涉及网络的部分只有区区 50 页,看完之后依旧懵懵懂懂。你应该去买一本 500页,由浅而深,内容完全涵盖所有 Java 网络相关议题的书,看完这样的书,你差不多也可以算是 Java 网络专家了。有了「主题专一」的书,你就可以不必去买一本 95% 的内容对你没帮助的书。你可以想学什么,就挑什么。

新版本推出较快:Java 逐年在改版,书的内容也会跟着翻新,通常「主题专一」型的书比较能快速且完整地反应技术的改变。

许多出版社都有主题专一的 Java 系列,但其中规划最完整、内容最受肯定的就非 O'Reilly 的「 The Java Series」莫属了(可能和他们请了一个优秀的 Java 编辑有关)。 你可以到国外许多线上买书的网站上看看大家对于 O'Reilly「 The Java Series」的评价,就会知道我所言不假。

目前, O'Reilly Java 系列的书共有约二十(还在增加当中),我差不多全买齐了,虽然花了不少钱,但是值得。如果你认真的想学习 Java,我向您推荐 O'Reilly 的「 The Java Series」。套句傅培梅的广告词「教人 Java 三四年,这是我用过最理想的书」。

在后续的文章,我将陆续为大家介绍 O'Reilly Java 系列的每一本书。

Learning Java the O'Reilly's Way (Part II)

Java in a Nutshell A Desktop Quick Reference

O'Reilly 的「in a Nutshell」系列书籍向来以简洁、不拖泥带水著称,常常一两页的内容可以抵得过其它书籍十多页的篇幅,在计算机书籍内容灌水风气盛行的今天,O'Reilly 的「in a Nutshell」系列可以算是个异数。「in a Nutshell」系列的每本书虽然薄,但该说的内容一件不少。除了简洁之外,「in a Nutshell」还有一个特色,就是同时具备 入门学习和参考查阅的双重功效。书的内容包含两部分,前面的部分是深入浅出的入门教学,后面的部分是参考资料。

《Java in a Nutshell》第一版是 O'Reilly「in a Nutshell」系列的第一本,目前本书最新的版本是第二版。《Java in a Nutshell》第二版厚度约共六百页,前面的223页是入门 教学,后面的部分是参考手册。如果,你能把本书前面薄薄的223页读懂,你的 Java 内功就会十分扎实。

C/C++ 和 Java 在语言上有许多相似性,所以 C/C++ 的程序员想跨入 Java 的领域比其它语言的使用者占了许多便宜。让我打个比方:C/C++ 的程序员只消翻过一道矮墙就可以从 C/C++ 的王国进入 Java 的领域。对于已经熟悉 C/C++ 的程序员来说,他们最希望能有 Java 书籍直接告诉他们 C/C++ 和 Java之间大大小小的差异,来让他们快速地将他们所惯用的 C/C++ 思维转成 Java 的思考方式,《Java in a Nutshell》正是这样的一本书。虽然后来有不少书籍也定位成 C/C++ 的程序员快速学习 Java 的书,但都没有《Java in a Nutshell》写得精彩完整而小巧。

在写 Java 程序的过程中,免不了要查一些资料,特别是API的用法,这时候,你会发现《Java in a Nutshell》后半部三百多页的参考资料超乎想象地好用,在良好的编排以及索引 的引导之下,你可以轻松地查到你需要的资料。

本书后半部的参考资料部分有两种查阅方式,方法一是透过 package 找 class,再透过 class 找 method或 field,这部分的参考资料在第十七章到第三十二章,通常使用这种方法 的人对于他所欲查询的 API已经有了大概的预期;方法二是完全没有概念时,直接透过第三十三章的字母排列方式找到他所欲查的资料,之后再透过方法一来找到详细的说明。

以前,《Java in a Nutshell》一书是许多人写 Java 程序时必备的速查手册,但现在因为许多 Java 开发工具都提供了方便的线上辅助工具,比方说:Borland JBuilder 可以透过 sensitive help(也就是F1按键)来找到你感兴趣的 API、或透过 Code Inside 之类的神奇功能来提示你某 API 的用法、或透过线上文件(支持hyper-link)来交互查阅,所以现在《Java in a Nutshell》的参考手册的地位已经不再像以前那般地重要了。

本书在 Java 书籍中已经建立了权威的地位,一提起 Java 的好书,大家第一本想到的就是本书,在 Java书籍泛滥的今天,要写出一本这样令大家共同推崇的书实在不容易,而 这也是我对本书作者 David Flanagan 至感钦佩的地方。有读者说:『Flanagan 唯一的缺点是---写的书还不够多』。这真是对一个作家最极至的赞美。

为了达到精简的目的,内容就必须有所取舍,不能大小通吃。比方说,本书就只包含 core API,对于standard extension API(也就是javax package)则完全略去,而 core API 中也有少数的 package 被舍弃在外(作者打算另外写一本《Java Enterprise in a Nutshell》来容纳部分本书未包含的内容)。

同样为了精简的目的,本书相当缺乏完整的程序范例,作者另外写了一本《Java Examples in a Nutshell》来弥补这项不足。《Java Examples in a Nutshell》的程序范例之多, 媲美 The Waite Group 出版的《Java How-to》。我在后续的文章会介绍到《Java Examples in a Nutshell》。

评书的好坏时,不宜讨论到书的价钱,但我实在忍不住要说:这本书的定价实在便宜得夸张,只需美金19.95。如果你常买信息类原文书的话,你会发现大部分的书都是 30 到 60 美金,而且在这些高价位的书籍当中不乏烂书,这更衬托出《Java in a Nutshell》这本书实在「俗搁大碗」。其实,《Java in a Nutshell》就算卖三四倍的价钱我还是 会乖乖掏出钱来买的。

尽管这是一本好书,不过我还是要提醒各位读者,如果你没有 C/C++ 的背景,就想透过本书来学习Java 的话,恐怕你会铩羽而归。在本系列后续的文章中,我会介绍一本不要求读者具备 C/C++ 背景的 Java 入门书。

Learning Java the O'Reilly's Way (Part III)

Java Examples in a Nutshell

许多程序设计初学者常有的困扰是:即使查到 API 的用法,也不知道怎么样将这些 API 兜在一起写出想要的程序。其实,个别的 API 作用有限,如何将数个 API 结合起来解决问题才是学习程序设计的重点。对于许多人来说,有一本范例丰富的书可以观摩学习,这比什么都来得重要,也因此,以范例为导向的书向来颇受好评。《Java Examples In a Nutshell》正是这样的一本书。

隔了整整三年,《Java Examples in a Nutshell》一书终于推出第二版。新版本涵盖 JDK 1.3,比起前一个版本多出近六十个主题,共有约一百六十个主题。依据属性,本书内容分成三部份,分别是「Part I:Core Java APIs」、「Part II:Graphics and GUIs」、「Part III:Enterprise Java」,这三部份刚好涵盖了「Java 基础」、「JFC」、以及「Enterprise Java」三大领域,所以此书可以视为《Java in a Nutshell》、《Java Foundation Classes in a Nutshell》以及《Java Enterprise in a Nutshell》的范例教学版本。

此版本和前一版比较大的差异是:

大幅改写安全和加密的部分,因为 Java 在此领域有了不小的变动。l
新增对 GUI 的基本介绍l
绘图的部分以 Java 2Dl 为主轴全部改写。
新增打印的部分l
新增「data transfer」的部分(包括 copy-paste 以及l drag-and-drop)
新增 Servlet 和 JSPl
新增 XML 的部分(包括 SAX、DOM、JAXP、JDOM)l

旧章节的重新安排和改写,以及新章节的加入,使得本书比起第一版更有条理,适合一章一章地循序阅读。除了一般的索引之外,本书第二十章还特别编排了「范例索引」,可用来快速地查阅到需要的范例。本书章标题条列如下:

PART 1: Core Java APIs
Chapter 1. Java Basics
Chapter 2. Objects, Classes, and Interfaces
Chapter 3. Input/Output
Chapter 4. Threads
Chapter 5. Networking
Chapter 6. Security and Cryptography
Chapter 7. Internationalization
Chapter 8. Reflection
Chapter 9. Object Serialization

PART 2: Graphics and GUIs
Chapter 10. Graphical User Interfaces
Chapter 11. Graphics
Chapter 12. Printing
Chapter 13. Data Transfer
Chapter 14. JavaBeans
Chapter 15. Applets

PART 3: Enterprise Java
Chapter 16. Remote Method Invocation
Chapter 17. Database Access with SQL
Chapter 18. Servlets and JSP
Chapter 19. XML
Chapter 20. Example Index

「Part I」对于 Java 语言基础与重要的 API 有很精简的介绍。如果你具有丰富的程序经验,你甚至不需要会 Java 语言,就可以直接透过 Part I 的范例来学会 Java。

「Part II」对于 GUI 程序设计的介绍很精简。本书对 Java 2D 的介绍或许对许多读者来说已经够用,但是本书对 Swing 的介绍绝对不够,毕竟 Swing 是个超级大的主题。

「Part III」是 J2EE 的部分。可惜的是没有介绍 Enterprise JavaBeans(EJB)。比较特别的是,本书有一章介绍了 Java 的 XML 程序设计。

「学一个东西最好的方法就是去用它」。本书有许多范例程序,都是相当精简而具代表性的。如果你是初学者,本书可以让你边做边学,学习效果加倍。即使你不是 Java 初学者,本书也可以提供你速查的功用。以我的经验来说,我懂得 RMI,但是我不可能将 RMI 的程序细节一一记在脑海中,当我要写 RMI 程序时, 我会翻出此书第十六章 RMI 的部分,看看书上详细的作法。

本书也相当适合当作 Java 课程的辅助教材,每个单元后面都有几道程序习题,书上或 O'Reilly 网站上没有这些习题的解答,所以这些习题可供教师当作学生的作业,也可以当作自我练习的题材。

依照 O'Reilly 的惯例,除了极少数的例外,书一律不附光盘片或磁盘,本书也是如此。这虽然会造成部分读者的不便,但其实也有不少好处。通常附上光盘片的书成本提高,售价也会提高;而且 O'Reilly 的网站上都会免费提供相关程序或资料的下载,用下载的方式可以确保读者们取得的程序和资料是最新版本的。以本书来说,我建议各位善用此资源下载程序回来,因为本书中的程序范例相当具代表性,常常只需要做小部分的修改就能符合自己所需,如果能有原始码的档案就可以透过 copy-paste-modify 的方式省下不少敲键盘的时间。

Learning Java the O'Reilly's Way (Part IV)
Exploring Java, 2nd Edition (本书的第三版,改名为 Learning Java)
O'Reilly 的 Java 入门书有两本,一本是《Java in a Nutshell》,另一本是《Exploring Java》。O'Reilly 的 Java 系列书籍在出版前就已经做了良好的规划,所以 虽然《Java in a Nutshell》和《Exploring Java》都是 Java 入门书,但定位却截然不同。《Java in a Nutshell》定位为「让 C/C++ 程序员快速学会 Java,且可以当作 API 速查手册」的书;而《Exploring Java》则是定位成「一般的入门书,不限定读者的背景」。

《Java in a Nutshell》比较着重在 Java 语言教学和 Java 语言相关特色的描述,许多常用的 API 都没提到,所以许多人读完《Java in a Nutshell》之后只知道自己学会 Java 语言了,但是还是写不出 Java 程序。我认为这样的读者应该在读完《Java in a Nutshell》之后,开始阅读《Exploring Java》。《Exploring Java》介绍了许多常用的 API(比方说: java.awt、java.io、java.rmi、java.net、java.util),这些 API 都是每个 Java 程序员必须知道的。在阅读完《Exploring Java》之后,你差不多就可以写出 大部分的程序,《Exploring Java》可以让你对 Java 有一个整体的概念。有了《Java in a Nutshell》和《Exploring Java》的基础之后,设计程序如果遇到更深入或更专门的问题 ,你可以去查阅 O'Reilly 的其它 Java 书籍。

本书内容包含相当广,下面列出本书的内容大纲:

Chapter 1. Yet Another Language:介绍 Java 的基本概念、优点、和用途。
Chapter 2. A First Applet:一个简单的 applet范例
Chapter 3. Tools of the Trade:介绍 Java 直译器、类别路径、编译器、Applet 在 HTML 的用法、JAR、安全性
Chapter 4. The Java Language:说明 Java 的基本型态、语法、例外处理、数组 … 等。
Chapter 5. Objects in Java:Java 的类别和对象
Chapter 6. Relationships Between Classes:说明继承、接口、Inner Class … 等主题
Chapter 7. Working with Objects and Classes:说明 Reflection 的相关主题
Chapter 8. Threads:介绍执行绪和相关的主题
Chapter 9. Basic Utility Classes:介绍一些常用的辅助列别
Chapter 10. Input/Output Facilities:介绍stream的观念和用法,并包括档案、Serialization、数据压缩等主题。
Chapter 11. Network Programming with Sockets and RMI:包括了TCP/UDP Socket,RMI等主题。
Chapter 12. Working with URLs:包括了URL、Content Handler、Protocol Handler等主题。
Chapter 13. The Abstract Window Toolkit:介绍Component、Container、Lightweight Component的观念;说明Applet和AWT的关系;介绍Java Event Model。
Chapter 14. Creating GUI Components:介绍AWT常用的组件
Chapter 15. Layout Managers:介绍AWT的Layout Manager,也说明如何设计出自己的Layout Manager。
Chapter 16. Drawing with AWT:利用AWT来绘图
Chapter 17. Working with Images:利用AWT来进行影像处理
Chapter 18. Java Beans:基本JavaBeans的观念
本书用了相当多篇幅介绍 AWT,甚至连许多 AWT 进阶用法都讲得很详细,所以如果你有了本书,你就不太需要购买 O'Reilly 的《Java AWT Reference》了。

本书有一些小缺点,包括了:

少部分内容过时:虽然本书内容大致上没问题,但它毕竟是两年前出版的书,所以少部分信息已经过时了,比方说:执行绪、java.util 等。目前,第三版正由 Jonathan Knudsen 撰写中。Jonathan Knudsen 称得上是 Java 的全才型作家,不管是 Java 2D 图学技术、Java 密码学、JavaSound、Java AWT/Swing…等多种不同领域他都相当专精。 目前他也为 O'Reilly 美国网站撰写「Byte-Size Java」专栏,我的「啜饮 Java 系列」正是翻译自他的文章。我相当喜爱他的作品,也希望他的《Exploring Java 3rd Ed》早日问世。
虽然《Exploring Java》定位成「一般的入门书,不限定读者的背景」。不过,以《Exploring Java》的撰写方式来看,我认为读者必须要有程序设计背景(可以是 BASIC 、Pascal、C/C++…)和对象导向基本概念,否则这本书还是太难。
范例都是片片断断的,无法让读者对整体有良好的认识。
赘词太多,不像《Java in a Nutshell》的简洁。
虽然有一些缺点,但是瑕不掩瑜。我正期待下一版的早日出现,也希望下一版够把那些讨论 AWT 的篇幅留给 Swing。


Learning Java the O'Reilly's Way (Part V)

Java Threads, 2nd Ed.

在 Windows 程序设计中,不是每个程序员都需要使用到执行绪,但对 Java 的程序员来说,想写出一个真正的 Java 程序(那些交作业用的小程序不算),几乎都会用到执行绪。执行绪之所以在 Windows 和 Java 中的重要性不同,原因有二:

· Windows 的 event-driven 方式和 Java 的 event model 不同: Windows 提供许多 non-blocking API、call-back function 机制;而 Java 的 API 都是 blocking 形式的,如果不想阻碍程序的进行,就必须使用执行绪。

· Windows 可以设定 timer(WM_TIMER 讯息),但 Java 不支持 timer ,必须利用执行绪来仿真 timer 。

除此之外,下面列出两点也需要使用执行绪的时机:

某件工作如果独立而冗长,使用执行绪可以让使用者可以不用枯候,甚至有可能提升执行效率。

使用平行算法时,也需要使用执行绪。

因为执行绪对 Java 来说实在太重要了,所以 Java 程序员有必要彻底了解执行绪的一切,才能驾驭得当。对 Java 执行绪说明得最完整而清楚的书,正是 Scott Oaks 和 Henry Wong 所合着的《Java Threads》。(注:其实由 Addison-Wesley 所出版, Doug Lea 所着的《Concurrent Programming in Java》也相当不错,可惜写得相当难懂,而且没有推出新版本。)

许多人认为执行绪很难,其实不然。「绪可叙,非常序」,教导执行绪时,正确的顺序很重要,否则读者可能会懵懵懂懂、一知半解。我认为《Java Threads》在这方面做得很好,它以循序渐进、引导的方式教导读者执行绪的正确使用方式,所以即使读者原本对执行绪一点概念都没有,也能轻易地阅读并理解其内容。 下面列出此书的大纲和顺序:

第一章,Introduction to Threading:简单地介绍 thread。
第二章,The Java Threading API:介绍 Java 最基本的 thread API。
第三章,Synchronization Techniques:介绍多执行绪时要注意的同步化问题。
第四章,Wait and Notify:如何善用 wait() 和 notify() 来避免 busy waiting。
第五章,Useful Examples of Java Thread Programming:透过几个范例程序让你能体会执行绪的使用方式。
第六章,Java Thread Scheduling:自行控制执行绪的排程方式。
第七章,Java Thread Scheduling Examples:执行绪排程的范例。
第八章,Advanced Synchronization Topics:如何避免 deadlock、starvation ,如何设计出 thread-safe 的类别。
第九章,Parallelizing for Multiprocessor Machines:在多 CPU 的机器上,执行绪的相关问题。
第十章,Thread Groups:如何利用 Thread Group 来管理 thread。
附录A,Miscellaneous Topics:讨论一些前面未触及的执行绪问题。
附录B,Exceptions and Errors:讨论执行绪相关的例外和错误。

本书提供了许多简短的范例程序,让读者更能体会作者所欲陈述的内容。第五章更设计了一些实用的例子,让你了解 thread 程序设计的方式和应用所在。

相当特别的是,本书大量采用引导式教学:先提出一个问题,然后提出一个直觉上的解决方法,再说明这个方法为什么行不通,最后告诉读者正确的方法为何。我相当 喜欢这样的陈述方式,让人有「山穷水尽移无路,柳暗花明又一村的」感觉,体会也因此更加深刻。

即使你认为自己已经懂得 Java thread 程序设计,我还是建议你看看此书,你将会有许多意料之外的收获,而这些收获对你以后的 Java 程序设计会有相当大的帮助。


Learning Java the O'Reilly's Way (Part VI)

Database Programming with JDBC and Java, 2nd Edtion

数据库一直都是程序设计最重要的主题之一。如果某程序语言或平台开始提供数据库的 API,我们可以说它已经正式脱离玩具的阶段,开始具备实用的价值了。

JDBC 是目前 Java 唯一的一套数据库 API。也可以说是 Java 技术中,先定义规格,再由厂商实作 Service Provider,第一个广为接受的成功例子。现在,除了微软的数据库产品之外,其它的数据库产品几乎都有厂商所提供的 JDBC 驱动程序。也因此,Java 程序可以很轻易地存取所有的数据库,而不用改写程序。微软的数据库产品虽然不提供 JDBC 驱动程序,但是 Java 程序可以透过 JRE 内附的一套 JDBC 转 ODBC 的驱动程序,或向其它厂商购买微软数据库的 JDBC 驱动程序,所以 Java 程序依然可以存取微软的数据库产品。

在 Enterprise JavaBeans(EJB)技术流行之后,程序员直接使用 JDBC API 的机会似乎大减,因为 Container-Managed Entity Bean 会在部署的时候自动产生数据库相关的程序代码。虽然如此,但还是有许多时机需要直接去存取数据库,所以 JDBC 的知识对于多数 Java 程序员而言仍是必备的。

由 O'Reilly 出版,George Geese 所着的「Database Programming with JDBC and Java, 2nd Ed. 」正是着眼于 JDBC 这个重要的主题,它的内容大致上可以分成三部分。

第一部份:第一章到第五章,讲述 JDBC API 的用法,包括了 JDBC Core API 和 Standard Extension API。这部分可以说是涵盖了 JDBC 全部的 API,但是令人失望的是,解说并不够深入。
第二部分:第六章到第十章,对于利用 JDBC API 来设计系统架构,有很精辟的说明。这部分的内容让本书的价值大大地提高了。
第三部分:第十一、十二章,是 JDBC API 的完整列表,但是感觉像是从 Javadoc 抄出来的,有些粗糙。
下面是各章的内容介绍:

第一章:本章解说 Java 运用在企业内部的方式。我发现本章有一部分是沿袭自很久以前的本书第一版,并未在此新版本中修订,内容有点过时。

第二章:本章对于关系型数据库和 SQL 的解说有很简单的介绍。SQL 语法对于 JDBC 程序员来说是必备的知识,所以本章对于原本不懂 SQL 语法的读者来说,是很重要的。当然,原本完全不懂 SQL 的人,看完此章之后还是不够的,需要另找 SQL 和关连式数据库的书补充这部分的知识。

第三章:开始介绍利用 JDBC 存取数据库的方式。如果你不讲究效率或其它议题,那么看完本章之后就可以开始利用 JDBC 写数据库程序了。

第四章:本章讨论 JDBC 进阶主题,包括加快速度存取的方式、Stored Procedure、Metadata 等。

第五章:解释 JDBC Standard Extension API 的用法,包括了联机管理、分布式交易等。

第六章:介绍 JNDI、RMI、EJB 等 J2EE 重要的技术。

第七章:透过一个银行系统的范例,解说分布式架构。

第八章和第九章:讨论分布式运算和数据库会遇到的问题,包括:交易、安全、储存。

第十章:如何利用 Swing 的组件来呈现资料。

第十章和第十一章:列出所有的 JDBC API。

如果你完全没有数据库的基本概念,这本书可能不适合你。如果你需要 JDBC 的 API 查询手册,这本书也不是很适合。这本书的主要价值在于让有数据库经验的程序员,透过第一部份很快地熟悉 JDBC API,再透过第二部分的启发而设计出良好的多层式系统架构。

虽然本书内容涵盖了目前最新的 JDBC 2.0 版,但是我必须提醒你:

· JDBC 3.0 会随着 JDK 1.4 而现身。

· JDBC 是目前官方唯一的 Java 数据库 API,但是未来 JDO(Java Data Object) API 会正式成为官方的 Java 储存 API,重要性甚至会凌驾 JDBC。

· 虽然 SQLJ 短期内被纳入官方标准的机会很低,但是 Oracle 和 IBM DB2 都支持 SQLJ,而且 SQLJ 使用上也的确有一些方便的地方,值得注意。

在看完这本书之后,你可以继续看下列两本书:

· JDBC API Tutorial and Reference, Second Ed. (Published By Addison-Wesley)

· Understanding SQL and Java Together (Published By Morgan Kaufmann)

Learning Java the O'Reilly's Way (Part VIII)

Java Swing

现代的程序中,图形化的使用者接口(GUI)相当重要,良好的GUI可以让程序更具吸引力、更好操作、更容易学习。虽然 Java 早就有 AWT,可以用来设计 GUI,但是 AWT 有两大缺失:

太阳春:AWT 只提供最基本的组件(比方说:按钮、滚动条等),而不提供 TreeView 等现代化GUI组件。更糟的是,AWT 的组件还只提供最基本的功能,比方说:按钮上面只能出现 文字,不能出现图形。(当然,你也可以利用继承的方式来设计出图文兼容的按钮,但这还要花不少额外的时间。)
不能跨平台:AWT透过「同侪系统(peer system)」来和操作系统沟通。每个使用者接口的对象都有一个对应的「同侪对象(peer object)」,用来管理操作系统所提供的真正 使用者接口对象。比方说:如果你建立一个按钮(Button)对象,就会有一个按钮同侪(ButtonPeer)对象一请被建立,此按钮同侪对象会请底层的操作系统建立一个真正的按钮。 如果此程序是在 Windows 98 上执行,所建立的按钮自然是 Windows 98 的按钮。AWT 组件的外观就会受到底层操作系统的影响。
正因为 AWT 的这两大缺点,所以许多软件组件厂商纷纷推出它们的GUI组件库。比方说,Inprise/Borland的JBCL,KL Group 的 JClass。使用这些协力厂商的 GUI 组件产品固然解决 了 AWT 的两大问题,但是因为非标准 API,所以必须随着软件的发行而附上,不但组件使用授权需要额外的花费,使得软件成本上升,而且软件体积也因此变大许多。

如果能有一套免费、统一、完善、又可跨平台的 GUI 组件库的话,那该有多好!

Swing 正是这样的产品,它是由 Sun 公司研发设计。有了 Swing,上述的问题都迎刃而解。Swing 不但填补了 Java GUI 不能跨平台的缺点,也提供许多新的组件,可以用来组合出 复杂的使用者接口,除此之外,Swing 也为 Java 注入新的特色,支持包括了拖放功能(drag-and-drop)、复原(undo)、并允许使用者改变 GUI 的外观(look and feel)。Swing 组件都是「轻量级的(lightweight)」(注:前述的 Inprise/Borland 的 JBCL,KL Group 的J Class 也都是轻量级组件)。

Swing 提供了这么多特色,所以我们该学的东西也不少,Swing 比 AWT 复杂许多,想直接透过 Java Swing API 的文件来学习如何将 Swing 完全驾驭得宜实在不太可能 (比方说:JTable、JTextPane、和 Look-and-Feel 这么复杂的东西,我不相信有人光靠 Swing Javadoc 简单的说明就能操控自如)。我们需要一本好的 Swing 书籍,除了教学功能, 也要能当 API 速查手册。

由 Robert Eckstein、Marc Loy、和 Dave Wood 合着的《Java Swing》深入地涵盖了 Swing 的一切,也正因为如此,它的厚度高达 1,200 页。本书以 Swing 大架构的解说为开始, 接着分门别类、由浅而深地介绍 Swing 的每个类别。O'Reilly 的书向来附图不多,但本书可以算是个异数,不但有许多类别继承图,更有不少示意图和GUI的画面。本书还有许多表格、 详细地列出类别的 method 和 field。由于 Swing 组件一般都是搭配 RAD 工具(例如 JBuilder、VisualAge for Java)来当作 bean 使用,所以这些表格还贴心地标出 get、set、is、 这些和 bean access 相关的 method。本书也有不少范例,让读者可以马上知道相关用法。除了利用本书来学习 swing 之外,本书也相当适合当作案头查阅书,我把它放在计算机桌旁 随手可及的地方。

就像 Windows 有一些未公开的 API,Swing 也一样,本书辟一个章节告诉你这些好用的 API(比方说 timer)。另外,如果你对 Swing 内部运作原理感兴趣,本书也有一章完整的 说明。这些内容在其它书并不容易看到。

除了介绍一般的 Swing 之外,本书也涵盖了Look and Feel、Accessibility、Undo。本书关于 Look and Feel 的部分写得尤其精彩。但是,请注意:本书不包含 Drag and Drop。

你还是觉得无法随心所欲地控制 Swing 的某些组件吗?你需要看看这本书,你会发现,其实 Swing 没什么好怕的。


Learning Java the O'Reilly's Way (Part IX)

Java 2D Graphics

在看过 Direct3D 和 OpenGL 之后,你一定会以为图学的 API 都很复杂难用,那么你应该瞧瞧 Java 2D 和 Java 3D,相信你一定会改变你的想法。Java 2D 和 Java 3D 整合进了对象导向的观念来以简驭繁,Java 程序员可以轻易地绘出令人赞叹的 2D/3D 图形。想学绘图程序设计,却又在接触 Direct3D 和 OpenGL 之后铩羽而归的读者,不妨改从 Java 2D/3D 下手。

O'Reilly 已经出版了一本 Java 2D 的书,书名叫做「Java 2D Graphics」,本书中文版也即将于 2000 年 9 月出版,中文书名为「Java 2D 绘图技术」。「Java 2D Graphics」一书是由 O'Reilly 的王牌作者 Jonathan Knudsen 所着。不过,目前 O'Reilly 尚未出版任何 Java 3D 的书。在详读过「Java 2D Graphics」之后,我倒很希望 Jonathan 再写一本「Java 3D Graphics」来造福读者(顺便造福我)。

不要以为只有设计绘图程序或游戏软件才会用到 Java 2D,其实 Java 2D 的用途可能远比你想象来得广泛。我认为,只要你的程序有 GUI,就很可能会用到 Java 2D。因为 AWT 和 Swing 的组件常常无法完全适合我们,这个时候自己绘制一部分的 GUI 就有绝对的必要。如果,你的 Java 程序需要 GUI,那么我建议你早点把 Java 2D 学好,以备不时之需。以我自己的例子来说,我正在开发一套软件,需要提供一个表格状的 GUI,而 Swing 的 JTable 却不适合我使用,因为我的表格需要能在同一个 column 的不同 cell 放进不同种类的组件,我也需要 cell 之间能够合并,我还需要有特殊的 selection model...... 这些都是 JTabel 不支持的,所以我就用 Java 2D 自己绘制这一切。有了 Java 2D 的帮忙,这一切简单多了,而呈现出来的视觉效果也很不错(当然,一方面要归功我的美术细胞,谢谢你们!我的美术细胞们)。

Java 2D 是 Core API,所以使用 Java 2D 的程序不需要额外安装任何 package。其实,AWT 和 Swing 都是透过 Java 2D 来进行绘图的。

你可能会问,Java 在 1.0 和 1.1 就有绘图的 API 了,为什么在 Java 2 (JDK 1.2) 之后还要多出一个 Java 2D。其实,Java 2D 比起以前的「阳春绘图 API」可是功能强大许多, 下面列出以前「阳春绘图 API」的几点局限之处:

* 所有线条只能用单一像素的宽度画出。
* 只能使用少数几种字形。
* AWT 没有提供很多绘画控件目。举例来说,你无法操纵单一字符的形状。
* 如果你想要旋转、或放大缩小任何对象,必须要自己动手进行数学运算才能达成。
* 如果你想要进行渐层或花纹等特殊着色方式,必须自己动手做。
* 只提供最基本的影像功能。
* 要控制透明度,必须大费周章。

这些都已经在 Java 2D 中得到解决。如果这些文字叙述无法让你感受到 Java 2D 的威力,那么请打开你的计算机执行 JDK 所附的一个范例程序:

C:\> cd \jdk1.3\demo\jfc\Java2D
C:\jdk1.3\demo\jfc\Java2D> java -classpath Java2Demo.jar Java2Demo

很惊人,是不是?呵呵!还有更吓人的呢!请看 Vincent J. Hardy 所着的「Java 2D API Graphics」(Sun Press 出版)一书所附的一堆彩色图片,保证你会大吃一惊。没错!这都是用 Java 2D 做出来的。(可不是 Corel Draw 呦!)

绘图本来就是很复杂的一件学问,Java 2D 的 API 虽然好用、易扩充,但是前提是:你要彻底懂它的原理和架构。这时候,一本深入浅出,说理清楚的入门书就有必要了,我认为 Jonathan 所着的这本书很适合用来引导程序员学习 Java 2D,是一本初、中阶的书。而 Vincent J. Hardy 的「Java 2D API Graphics」(Sun Press 出版)也是一本很棒的书,较偏中、高阶。在读过 Jonathan 的「Java 2D Graphics」之后,我建议读者再继续把 Vincent J. Hardy 的「Java 2D API Graphics」一书读过,因为 Vincent J. Hardy 的书中有介绍光影变化等进阶的主题,还附有作者自行开发的 GLF(Graphics Layer Framework),让程序员可以轻易地叠出漂亮的视觉效果。Vincent J. Hardy 目前是 Sun 的员工,所以 GLF 目前虽然是 com.sun.glf,但我觉得 GLF 以后有可能会变成 javax.glf,因为 GLF 实在好用。

在读过 Jonathan 的书之后,读者都会很喜欢 Jonathan 的写作风格,因为 Jonathan 可以把复杂的原理用浅显的方式来表达,「Java 密码学」如是,「Java 2D 绘图技术」一书亦如是。因为喜欢这本书,所以我接下本书中文版的技术编辑,希望中文版能让你满意。

Learning Java the O'Reilly's Way (Part XIV)

Java Virtual Machine

Java是近年突然窜红的新星,「保全」、「跨平台」......,大家对它的诸多特色津津乐道,但你可曾认真思考:是谁在 Java 的背后成就这些光彩的?

因为 Java 虚拟机器(Java Virtual Machine,简称 JVM)的屏障,所以 Java 程序可以跨平台;因为 JVM 进行多项验证,所以 Java 具保全性。.... 原来,JVM 是成就 Java 的一大幕后功臣。

顾名思义,Java 虚拟机器是一部假想的计算机,也是 Java 技术的核心所在,所有的 Java 程序都是在这部假想的计算机上执行的。Java 虚拟机器可以以多种不同的形式存在:以一般程序的方式存在,架构在 OS 之上,例如 java.exe;以操作系统的方式存在,架构在硬件上,例如 Java OS;甚至直接以硬件的方式存在,例如 JavaChip(不过我认为以硬件的方式存在的虚拟机器已经太「真实」,不适合叫做「虚拟」机器)。

本书读者群设定在熟悉 Java 语言并略懂 C/C++ 的程序员。本书的内容介绍性与教学性兼而有之,某些部份还可以当成参考资料来查阅。本书是一本以「彻底解说」为导向的书,书中有许多实用的信息以及 Java 虚拟机器程序范例。

本书是写来和 JVM 规格书作为互补之用的。JVM 规格书告诉我们细部的规则和语意,而本书提供了更多说明与深入浅出的描述,并伴随着许多范例让你亲自尝试。比方说:本书教你写出一个类别加载者(class loader)、透过假码(pseudo-code)的说明来揭露 instanceof 的运作细节、用 JVM 指令来写出一个 applet.... 等等。本书也舍弃一些内容不提,比方说:IEEE 格式、类别验证者(class verifier)的动作方式.... 等。不过,这些资料你分别可以在 O'Reilly 出版的《Java Language Reference》以及《Java Security》等书上找到详细的资料。

本书的结构分为三部份:第一部份是机器概观,第二部份是指令指南,第三部份是参考资料。如果你对 Java 虚拟机器不熟悉,你可能想把这本书拿到一个安静的地方,花些时间仔细地读完前三章。稍后,你可以回来读完第一部份的其它章节。如果你需要熟悉 JVM 的指令集,第二部份包含了所有 JVM 指令的快速浏览,并佐以适当的范例。或者,如果你需要查询某 Java 虚拟机器指令的操作细节,你可以到第三部份去看看,这部分以英文字母顺序排列,查询相当方便。

本书的中文版正是我以前翻译的「细说Java虚拟机器」,已经绝版了,市面上不容易看到。因为翻译此书的关系,我在 Java 虚拟机器花了不少功夫,也对 Java 有了更深入的认识。除非你有实际的需要,或和我一样好奇地想更深入了解 Java,不然其实大部分的人并不需要阅读本书。本书可能的读者包括了﹕

· 教师:如果你正在教编译器(compiler)课程,你可能想用 Java 虚拟机器当学生习作的平台,好处是可以让学生在各种不同的机器上完成这份习作。

· 业余爱好者:本书提供你一套工具,让你能在虚拟机器层级将 Java 操控于指掌间。

· 系统开发者:如果你正在开发一个 Java 执行时期系统(runtime system),或将 Java 移植到新的 平台,这本书能让你了解执行时期系统内如何分工合作。

· 程序员:透过本书与随书附赠的 Jasmin(茉莉)软件,你可以反组译类别、观察类别的内部、甚至 可以用组译器来实作重要的类别和 method。或者,你也可以藉由本书来了解 Java 的执行效率议题 并直接使用 JVM 建立应用软件。

· 语言实作者:如果你希望让 Java 虚拟机器也能执行某个你喜爱的程序语言,你打算实作此语言的 JVM 版本,本书对你会很有帮助。

· 计算机安全高手:Sun 公司要求 Java 可以保护你免于受到来者不善的程序之捣乱。本书帮助你能自行 控制这项权力。

本书以 Java 1.02 版为描述对象,而现在都已经跨过 Java 1.1,进入Java 2(JDK 1.2)的时代了。虽然 Java 历经这些改版,JVM 指令集和 bytecode 的格式并未有任何变动,所以本书依然适用于现今的 Java 2,也因此原作者似乎短期之内没打算改版。虽然 bytecode 的格式并未改变,但 Java 1.1 和 Java 2 以后的确是多出一些属性,包括了:「InnerClasses」、「Synthetic」以及「Deprecated」,都是本书未涵盖的,如果你正在实做 JVM 或 Java 编译器,请特别留心这部分。

本书提供许多范例﹐用来帮助读者了解 Java 虚拟机器。因为 JVM 规格书并未定义 Java 类别文件的文字格式(只有定义 Java 类别文件的字节格式),本书作者们开发了一套自己的 Java 虚拟机器组译器,叫作 Jasmin(茉莉)。Jasmin 需要用文字来描述 Java 类别文件,以简单易读的语法撰写,Jasmin 将其转成合适的类别档。使用 Jasmin,可以轻易地摸索出虚拟机器的原理。本书所有JVM 程序的范例都是由Jasmin 语法撰写。本书参考资料的部份对 Jasmin 语法和底层的 bytecode 格式有更详细的描述。作者「原本」免费提供 Jasmin,可以到 www.ora.com/catalog/books/javavm/ 下载 Jasmin。不过,不知怎地,我发现 Jasmin 的网页已经消失了,所以无法下载。因为 Jasmin 的版权属于作者而非 O'Reilly,所以现在如果你想取得 Jasmin,无法透过 O'Reilly,可能的方式有:

· 买 O'Reilly 的《Java Virtiual Machine》一书,随书所赠的磁盘中就有 Jasmin。

· 或在欧莱礼台湾该书的网页 www.oreilly.com.tw/chinese/java/virtual.htm 下载。

· 写 email 求作者 Jon Meyer 发发慈悲,email 一份 Jasmin 给你。

什么!你要我直接 email 给你!不成,不成,未经同意散播有版权的软件是违法的。你们不希望看到我坐牢吧

Learning Java the O'Reilly's Way (Part XVIII)

Enterprise JavaBeans, 2nd Edition

Java 的诸多特点,使得 Java 很适合用在企业运算(Enterprise Computing)领域,而 EJB(Enterprise JavaBeans)可以说是其中最重要的技术。目前除了微软之外,所有的 Application Server 几乎都是支持 EJB 的。

EJB 虽然重要,但是 EJB 的知识相当繁琐,不容易全盘理解,学习门槛很高。如果没有花时间好好弄清楚每一个环节,实做时一定会遭遇到重重的困难。所以,在想享受到 EJB 的好处之前,你需要一本带你跨越障碍的好书。

由 Richard Monson-Haefel 所着的《Enterprise JavaBeans, 2nd Ed》一书,可以说是最畅销的 EJB 书籍。去年年底的一个 EJB 研讨会,几乎人手一本此书(或中文版,或英文版)。

只要懂 Java 语言,你不需要是数据库或分布式运算的专家,你也能阅读本书。本书由许多相关的技术说起,慢慢带出这些技术的缺点,再导向 EJB 技术。前面章节以大局观,并未提及太多 EJB 细节,后面章节才逐渐加入更多详细的信息。如此一来,读者可以循序渐进,不会一开始就迷失在这些细节中,对 EJB 的好处可以有更深刻的体认。

如果你手上有一个 EJB 的计划正在进行或即将进行,你会觉得本书简直就是专门为你而写的。本书以一家虚构的游轮公司当作范例贯穿全书,有趣、生动又实用的内容安排,对于理解有很大的帮助。

本书第一章针对分布式对象、组件、伺服端组件、交易监控服务器做了完整的解说。接下来第二章解释 EJB 的大架构,并开始以游轮公司当范例设计出一些 EJB 程序,也藉此解释一些重要的 EJB API。第三章针对 EJB server 内部运作和 EJB server 所提供的服务有了精简的解说。基本上,在读完这三章之后,你就能够掌握 EJB 的大架构了。建议将此三章多读几次,这三章是分布式运算的精华。

第四章提供了介绍 entity bean 和 session bean 的程序设计介绍,但是略过一些细节,让读者能很快上手写 EJB 的程序。第五章是 EJB client 端的部分。这两章读完之后,你差不多已经会写 EJB 的程序了。

第六章和第七章分别对 entity bean 和 session bean 进行地毯式的详细介绍。许多观念其实前面章节都提过,再加上程序范例很多,所以虽然此二章的篇幅不小,但其实可以很快就看完。

第八章对交易(transaction)有相当清楚的说明,这个主题是其它书欠缺或讲不清楚的部分。第九章针对一些 EJB 的设计提出方针,这部分比较偏技巧面,如果你希望「Design Patterns」之类的书,你可以参考 Addison-Wesley 出版的《SanFrancisco Design Patterns》一书,O'Reilly 也有一本《Enterprise Java Design Pattern》的书正在撰写中,其它出版公司也会在未来出版类似主题的书。第十章详细介绍 XML 的配置描述文件。第十一章对于 J2EE 中和 EJB 关系比较密切者(包括 Servlet、JSP)做了一些介绍。让你知道 EJB 应该如何和其它 J2EE 的技术相互整合。

附录是一些相当有参考价值的资料。附录 A 是 EJB API 的解说。附录 B 利用 UML 画出许多 EJB 的状态图和循序图,可以说是「一图解千言」。附录 C 是 EJB server 厂商列表。附录 D 是 EJB 1.0 和 EJB 1.1 之间的差异比较。

我认为,本书的优点有:

* 对于分布式运算有深入浅出的介绍
* 不只教你 EJB 程序的写法,也让你知道 EJB 内部的原理
* 内容章节的次序安排循序渐进、易读易懂
* 对交易(transaction)有详细的讨论。很精彩!
* 对 EJB 1.0 和 EJB 1.1 有完整的讨论,并详细解释了两者之间的差异
* 提供许多精心设计的插画和表格让许多复杂的观念可以清楚地呈现

本书中文版《Enterprise JavaBeans 技术,第二版》集优秀的作者(Richard Monson-Haefel)、优秀的编辑(Michael Loukides)、优秀的中文版译者(黄奕勤)的努力,中文版译者甚至抢先在原文版公布戡误表之前就已经把书中的小错误几乎都修正了。目前本书作者正进行第三版的改版动作,以符合 EJB 2.0 的新规格。我们可以期待新版的原文书或许在年底前会出版,而我也希望本书的原译者可以继续担当本书第三版中文版编译的重任。除了他,我不知道还有谁可以把 EJB 的书翻译得如此好。


Learning Java the O'Reilly's Way (Part XIX)

Java Internationalization

「写程序很难,写中文的程序更难」这是许多程序员的心声。许多平台、语言、编译器、数据库、驱动程序 ... 对于英文以外的语言支持都不好,而使用双位的东方语言更是常常会遇到乱码的情况,这正是因为这些软件在开发时,没考虑到国际化(internationalization,i18n)的需求所造成。当这些不够国际化的软件欲进入另一个国家的市场,必须额外花费更多心力进行本土化(localization,l10n)的工作,才能符合当地的需求。

软件市场的国际藩篱早已经被打破,所以在规划软件的同时,最好能有 i18n 的考量。近年来,IBM 和微软的产品 i18n 得相当彻底,所以不太需要花时间进行各地区的本土化,这些公司的软件在英文版上市的同时,世界各地的版本几乎都能同时上市。i18n 不但减少他们各国版本在本土化时所需要的人力,节省成本,更可以让产品提早上市,抢得商机。比方说:几年前,MS-Windows 和 MS-Office 还没有全面 i18n 之前,中文版上市时间会延迟数月甚至半年以上。

许多人以为软件本土化只是软件和手册的文字翻译罢了,如果你也这么认为,那么就太天真了。各国不同的不只是文字语言,还有习惯、文化、法规 ...。所以单纯的翻译只是本土化的第一步,后续还有许多工作要进行。设计时没有 i18n 考量的软件,在进行本土化时会遇到许多困难,甚至很有可能要改写原始码。不但成本大幅提高,上市日期延后,甚至会有更多的 bug 出现。也因此,软件在一开始设计时,最好就把 i18n 考量进来,虽然会在初期带来些许的不便,但是结果却相当值得。

Java 不但希望能跨平台,也希望能跨国际、族群。所以 Java 对于多国语言有相当好的支持,让我们能开发出不同语言的使用者都能使用的软件。Java 对于 i18n 的支持,是相当先进的,除了全面采用 Unicode 并提供许多编码转换之外,更内建许多机制(最为人所知的是 Locale 和 String Boundle),让程序员能很简单地开发出 i18n 的程序。

比较可惜的是,Java 在语音的部分对于 i18n 的支持并不佳,毕竟语音辨识和语音合成的技术门槛太高,而 Java Speech 也很久没有动静了。我希望在以后 Java Speech API 出新版本时,能有完善的 i18n 考量,而且各国语音的实作版本也能陆续推出,在这方面最有希望的是 IBM。

由 O'Reilly 出版,Andrew Deitsch 与 David Czarnecki 所合着的「Java Internationalization」一书,广泛地涵盖了 Java i18n 相关的主题。本书的各章节介绍如下:

第一章:讨论国际化和本土化的一般观念,以及 Java 对国际化的支持。
第二章:分析世界各地具代表性的书写方式,包括西方的(由左至右)、东方的(任意方向)、和中东的(双向混合)。这章可以让你大开眼界。
第三章:讨论 java.util.Locale 相关的用法。所谓的 Locale 指的是:一个特定的地区(以政治、经济、宗教、语言 ... 来区分)。
第四章:讨论如何透过 Resource Boundle 来将程序和相关资源隔离。许多人都以为资源指的是字符串,但其实也可以是任何对象。
第五章:各种格式(货币符号,数字格式,日期时间格式 ...)的使用。
第六章:Unicode、各种编码与转码相关的议题。如果你常遇到中文变乱码的问题,这一章的知识对你来说应该会有帮助。《Java I/O 技术》一书对此已经有相当详细的讨论。
第七章:叙述文字的比对与排序相关的议题。
第八章:讨论字型和呈现文字的方式。部分主题在《Java 2D 图学技术》一书中有更完整的讨论。
第九章:介绍图形化的使用者接口对于 i18n 应该做的改变。不同的国家,可能会需要不同风格的 GUI。本章对此做一个概念性的解说,更详细的 GUI 信息可以从《Java Swing 基础篇》和《Java Swing 进阶篇》中获得。
第十章:讨论利用 Input Method Framework 来设计输入法,让 Java 程序所使用的输入法也能不受操作系统的影响。
第十一章:国际化的 web 程序设计。让 web(applet、servlet、JSP)也能够国际化,从不同的地方读取会得到不同语言的版本。
第十二章:叙述 Java 未来还可能针对 i18n 做出哪些改进。
附录 A:各种语言和国码
附录 B:Java 所支持的编码方式
附录 C:Unicode 的编码分类
附录 D:Java i18n 相关的 API 列表
附录 E:Java 各版本对于 i18n 支持的变革

这是一本 i18n 的入门书,不是百科全书,许多时候你会需要更进阶的信息,所以本书最后还列出许多参考资料。本书虽然是以 Java 为程序语言,但是书中所提到的这些概念,其实其它程序语言也可仿效采用。特别是,目前专门论述 i18n 的书很罕见,所以本书弥足珍贵。
关于编码和文字的部分,我建议各位在看完本书之后,继续看下面这两本书:

· The Unicode Standard, Version 3.0 (published by Addison-Wesley)

· CJKV Information Processing (published by O'Reilly)

关于文化习俗,你还需要另外收集资料来看,特别是文明悠久的地区,例如:以色列、埃及、阿拉伯、印度 ... 等国家的文化习俗比较不为我们所熟知。而且因为有些国家比较激进一点,所以尚未全盘了解文化习俗之前,不要随便推出当地版本,否则天晓得会出什么乱子。辟用几位当地人员作为本土化咨询顾问,似乎是可行的管道。

Learning Java the O'Reilly's Way (Part XX)

Java Enterprise in a Nutshell

Java 现在最热门的应用领域是在 Server 端。Java 2 Platform, Enterprise Edition(简称 J2EE)是 Java 在 Server 端的标准。现在,除了微软之外,其它的 Application Server 厂商几乎都是一面倒向使用 J2EE,由此可见 J2EE声势的浩大。再加上现在 Multi-Tier(多层)架构流行,电子商务 B2C 以及 B2B 当红,使得 J2EE 更加地水涨船高。

本书正是介绍 J2EE 相关技术的书。有经验的 Java 程序员适合以本书当作进入 Enterprise Computing 领域的向导,但无 Java 经验的程序员应该先把 Java 语言学好再谈。

本书涵盖的主题包括了:

· JDBC:关系型数据库的 API。

· RMI:对象导向分布式运算的 API,只能在 Java 程序之间使用。

· Java IDL:兼容于 CORBA 的对象导向分布式运算。

· Servlets:用来动态地产生网页的 API。

· JNDI:命名、目录、定位的 API。

· Enterprise JavaBeans:为公司内部设计组件化的 Business Logic 的 API。

可惜的是,本书没有提到 JSP、SQLJ、XML、JAXP。希望下一版能将这些主题包含进来。

在不多的篇幅中,每个主题至少都能从入门涵盖到中阶的程度,算得上是干净俐落,精确详实。在读完本书之后,如果欲学习更完整深入的内容,必须看个别主题的专书。

本书 JDBC/SQL 的参考资料写得尤其精采,用的篇幅不多,却可以巨细靡遗地涵盖 JDBC 的详细资料。本书还有一章是讲述关系型数据的概念和 SQL 语法,所以即使你以前对数据库 没什么概念,这本书依然适合。

本书也对 CORBA 有不错的入门介绍。如果你想学 CORBA,但是又实在没能力去读 Robert Orfali 和 Dan Harkey 所写的 CORBA 巨著,那么这本书倒是个适当的选择。

如同其它「in a Nutshell」系列的书一样,本书也在下半部附上了相关 API 的参考文件。虽然本书没有讨论 JMS 和 JTS/JTA,但是 API 的参考资料中倒是有将此二者包含进来。

「Java in a Nutshell」有一本范例导向的姊妹品「Java Examples in a Nutshell 」;如果本书也能有一本范例导向的姊妹品(比方说,就叫做:「Java Enterprise Examples in a Nutshell」),就更完美了,毕竟透过范例来学习可以比较容易体会这些Enterprise API 的用法。甚至,如果能设计一个完整的范例(比方说,电子商务)来将本书的 API 都用进去,会更棒。

聊点轻松的主题吧!本书封面的动物是「海胆」。海胆可以在世界上许多海岸的沙质底部找到。海胆的介壳常常有花瓣状排列的孔洞,海胆的嘴巴就在中心部位的壳底下。海胆可以 蠕动地在沙质海底表面挖洞。海胆可以在沙中找到其滋生的养分,它用管状的足部将食物推进嘴巴。海胆上方有一些特殊的管状足部是用来呼吸的管道。花状的美丽外观、以及遍布世界 的特性,使得海胆变成壳类收集家的最爱。科学家也被海胆所吸引,常常拿海胆当作研究细胞有丝分裂的题材。

O'Reilly 的书向来爱用动物当作封面,有的封面动物和书的主题之间有一些隐喻的关联。不过,我想了又想,实在不知道海胆和 J2EE 有什么关联。

Learning Java the O'Reilly's Way (Part XXI)

Java Power Reference

Java API 多得如恒河沙数,每个 Java 程序设计员都需要透过一套良好的 API 手册来帮助撰写程序。我心目中理想的 API手册是像 The Waite Group 出版的《Win32 API Bible》,依功能将 API 分门别类,然后详细介绍,还佐以短而具代表性的范例。

我认为 The Waite Group 出版的《Win32 API Bible》唯一的缺失在于它是印刷品。 API 手册如果以纸张印刷的方式存在,尽管索引方式设计得再精良,查询时仍然颇为费时、不便。更何况 Java 的 API 这么多,真要印成手册,恐怕会如大英百科全书般惊人。如果改以电子手册的方式存在,并以 CD-ROM 的方式发行,无疑地是 Java API 手册最好的现身方式,除了环保不需纸张的好处之外,查询检索起来更是方便,甚至可以使用交叉查询的功能。

《Java Power Reference》是一份电子手册,而且文件一律使用 HTML 的格式,所以可以直接用计算机上的浏览器阅读,无须安装特殊的电子书软件。除了一片 CD-ROM 之外,《Java Power Reference》还附有一本薄薄的书(约六十页),简单地描述 Java 2 平台的现况。

《Java Power Reference》的优点包括了:

· 搜寻方式以及交叉索引都很方便,找资料的速度比 Sun 的线上说明快。

· 完整地列出 Java 2 所有的 API。包括了 182 package、3,900 个类别、38,384 个 methods 和 field 。(虽然如此,但其实资料量也只占了光盘片的一小部分,约 130MB。)

虽然《Java Power Reference》是电子手册,收集了齐全的 Java 2 API(包括了Core API 和 Standard Extension API),搜寻功能和索引作得不错,也可以交叉查询,但是 它却让我大失所望。任何人都可以轻易地发现《Java Power Reference》的两大缺失:

· 没有范例程序:你无法知道如何将这些 API 兜在一起,以达到特定功能。

· 没有 API 说明:每个 method 只列出其传入参数的型态和其传出值的型态,其它的说明一概付之阙如。使用者只好透过 method 名称来「望文生义」一番。

没有范例、没有 API 说明的 API 手册,就好比是一本没有例句、没有单字说明的英文字典,我很怀疑这样的字典能帮我写好英文文章。对我来说,如果我想知道某 API 的用法,我宁愿利用 Sun 提供的线上文件,因为它对每个 API 有详细说明;如果我想快速查询 API 格式,我会使用开发工具提供的提示功能(比方说 Jbuilder 的 CodeInside)。

希望在不久的未来《Java Power Reference》能改版,加强范例和 API 说明,成为真正的 Java POWER Reference。

Learning Java the O'Reilly's Way (Part XXII)

Creating Effective JavaHelp

如果你设计过 WinHelp 格式的 online help,而且没有 help 写作工具的帮忙,那么你可能知道,其实制作 WinHelp 需要懂一大堆知识,包括 RTF 的格式、编译档案的方式 ... 等,所以 WinHelp 的书厚度总是不小,但是 Java 平台的 online help 就完全不同了。O'Reilly 最近出版的「Creating Effective JavaHelp」一书是讲解 Java 平台的 online help 制作,此书是 O'Reilly 的 Java 系列中最薄的一本书,只有 171 页,原因无它,只因为 JavaHelp 原本就是一个迷你的主题。JavaHelp 使用 HTML 当作说明档格式,使用 XML 当作附属档格式,使用一套 class(位于 javax.help 和 javax.help.event 此二 package)当作 Java 程序和说明文件之间的衔接桥梁。

虽然「Creating Effective JavaHelp」是目前唯一一本 JavaHelp 的专书,其实市面上几本 Swing 的书有讨论到 JavaHelp,而且都是用一章的篇幅就带过。但「Creating Effective JavaHelp」的定位不太一样,因为它除了教导 JavaHelp API 的用法之外,也教你建立「effective(有用的、实际的)」的线上说明系统,如书名所示。此书除了解说 JavaHelp 的使用方法之外,作者用了许多篇幅来讲解如何规划一套实用的 online help。这是比较难能可贵的部分。

如果你是 online help 设计的老手,你可以不用看此书,直接看 JavaSoft 的 JavaHelp 文件即可;如果你是 online help 的新手,那么这本书应该可以带你轻松入门。以我自己来说,因为我本来就懂 HTML 和 XML,又有制作 WinHelp 的经验,加上这本 JavaHelp 的书又很薄,所以我花了两天就差不多看完了。

虽然许多程序员都很「不屑」设计 online help,认为 online help 只是多余的东西。但是我认为 online help 很重要,特别是近年来许多软件的手册都电子化,使用者也习惯在操作软件时,一但遇到疑问,就去查 online help,如此一来可以快速地透过主题分类、搜寻、索引、交互查询等 功能,不但找资料的速度比翻手册快,还更环保呢!但是,我发现许多软件的 online help 做得不好,常会有 broken link,或者让我找了许久还找不到我要的说明,显然它们 的 online help 没有规划好。每次遇到这种情况,我都会 show 出我那不肯轻易示人的中指(其它指头成握拳状)。

最近,我正打算为我所写的软件加上 JavaHelp。如果你正使用 Java 开发软件,请别忘了把 JavaHelp 整合进去,而且多花一些时间规划出一个「effective」的 online help 吧!

Learning Java the O'Reilly's Way (Part XXIII)

Java Message Service

只要你正在使用 J2EE 规划 ERP、EAI、或 B2B 系统,你需要使用 JMS 的机会很大。如果 JMS 尚未进入你的系统规划中,我想可能是因为 JMS 相对于其它 J2EE 的技术(EJB、JSP、Servlet、JDBC)来说,是比较新的技术,所以你对 JMS 并不熟悉,因此忽略了它的重要性。J2EE 相关的技术有相当多,而且彼此多少有应用上的替代性。但是如果你错把某些功能规划使用不适当的技术来实作,系统或许仍可以完成,但建置成本会提高、开发时间加长、系统 稳定性会降低。如果你正在利用 J2EE 建置企业系统,但你还不知道 JMS,我强烈建议你花一些时间好好弄懂 JMS。很可能你的系统规划会因此而有很大的改变。

我一直很推崇 Richard Monson-Haefel,因为他不但具备企业运算的技术能力,而且知道如何将深奥的技术叙述得让人很容易了解,这样的作家实在不多。继广受好评的「Enterprise JavaBeans 技术」一书之后,Richard Monson-Haefel 偕同 David A. Chappell 写了「Java 讯息服务」这本主题同等重要的书,两本书的风格相当接近,「Enterprise JavaBeans 技术」的读者不应该错过「Java 讯息服务」。我认为 Richard Monson-Haefel 和 David A. Chappell 的这本「Java 讯息服务」可以说是 JMS 的经典之作,短期之内恐怕不会有其它 JMS 书籍可以超越本书的表现。

本书目前在 2001 年 JDJ 的读者票选中排名第三,仅次于第一的「Java in Nutshell」和第二的「J2EE Blueprint」。以一本如此 进阶主题的书,能仅次于 Java 入门书「Java in a Nutshell」,以及 J2EE 入门书(免费电子书)「J2EE Blueprint」,可见 JMS 的重要性。

Java 讯息服务一书完整地涵盖了 JMS 1.02 API。对于既有的讯息系统来说,点对点是最常见的讯息机制。但是本书却是先叙述出版订阅模式,再讨论到点对点。对于没有接触 过讯息系统的人来说,这是相当不错的方式。

对于完全不懂讯息服务器的人来说,这本书是一个很好的入门教材,对于已经懂讯息服务器的人来说,本书是相当好的 JMS API 参考资料,是你在实作 J2EE 系统时,不可或缺的一本好书。

本书的架构是这样的。第一章解释讯息系统、集权式与分布式架构、以及 JMS 的重要性。第二章到第五章详细地解说 JMS 客户端的开发细节,内容涵盖两种讯息模型(出版与订阅、点对点)。第六章到第七章可以被视为「进阶主题」,内容涵盖讯息系统的部署与管理。第八章是 JMS 在 J2EE 中所扮演的角色,内容包含了 EJB 2.0 新的讯息驱动 bean。最后,第九章提供了一些 JMS 厂商和产品的简单介绍。下面是本书各章的大纲:

第一章:了解讯息传递
本章告诉你何为企业讯息传送以及讯息服务器厂商常用的架构,本章涵盖了 JMS 的定义、运作的解释、以及两种程序设计模型(出版与订阅、点对点)。本章也列举出一些适合使用 JMS 的例子。

第二章:开发一个简单的范例
透过一个简单的聊天室系统,带领读者走过一次出版订阅模型的开发过程。

第三章:JMS 讯息内部细节
剖析 JMS 讯息内部的组成。包括讯息标头、属性、装载物。

第四章:出版与订阅
透过一个 B2B 系统的实作过程,来让读者对出版订阅讯息模型的程序设计方式有所了解。

第五章:点对点
运用点对点技术来加强前一章的 B2B 系统,以对点对点有深入的了解。

第六章:保证送达、交易、响应确认、失败
本章对于一些进阶主题有更深入的讨论,这些主题包括保证送达、交易、响应确认、与失败的处理。我非常喜欢这章,透过许多图形的解说,讯息系统内部运作机制一切都变得再 清晰不过。

第七章:部署考量
本章深入地剖析了选择 JMS 服务器以及部署 JMS 程序时必须考量的问题。

第八章:J2EE、EJB、以及 JMS
本章对于 J2EE 和 JMS 有整体性的描述。本章也介绍了 EJB 2.0 所支持的 JMS 讯息驱动 bean。

第九章:JMS 产品
对于常见的几套 JMS 产品,本章有简短精要的介绍和比较,这些产品包括了:IBM MQSeries、Progress SonicMQ、FioranoMQ、Softwired iBus、Sun JMQ、BEA WebLogic、Exolab OpenJMS。

附录 A:JMS API
对 JMS API 内的类别、接口、method 作一个简短的介绍。

附录 B:讯息标头
提供讯息标头的详细信息。

附录 C:讯息属性
提供讯息属性的详细信息。

附录 D:讯息选择器
提供讯息选择器的详细信息。

随着 JMS 快速地变成 J2EE 中最重要的技术之一,许多成功的分布式运算专家需要知道 JMS 的工作原理以及使用时机。阅读本书来学习 JMS,可能是你的职业生涯中最睿智的抉择之一。

从 Applet 到 Servlet,从 Servlet 到 EJB,从 EJB 到 JMS。大家都开始准备享受讯息服务所带来的好处,而你也准备好了吗?


本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/beseanlo/archive/2009/09/11/4543885.aspx

posted @ 2010-10-29 10:20 favorer 阅读(4434) | 评论 (1)编辑 收藏

2010年7月9日

理论与实践: 您的小数点到哪里去了?

转自:http://www.ibm.com/developerworks/cn/java/j-jtp0114/index.html

使用浮点数和小数中的技巧和陷阱

developerWorks
文档选项
将打印机的版面设置成横向打印模式

打印本页

将此页作为电子邮件发送

将此页作为电子邮件发送

未显示需要 JavaScript 的文档选项


级别: 初级

Brian Goetz (brian@quiotix.com), 首席顾问, Quiotix Corp

2003 年 4 月 20 日

许多程序员在其整个开发生涯中都不曾使用定点或浮点数,可能的例外是,偶尔在计时测试或基准测试程序中会用到。Java语言和类库支持两类非整数类型 ― IEEE 754 浮点( floatdouble ,包装类(wrapper class)为 FloatDouble ),以及任意精度的小数( java.math.BigDecimal )。在本月的 Java 理论和实践中,Brian Goetz 探讨了在 Java 程序中使用非整数类型时一些常碰到的陷阱和“gotcha”。请在本文的 论坛上提出您对本文的想法,以飨笔者和其他读者。(您也可以单击本文顶部或底部的讨论来访问论坛)。

虽然几乎每种处理器和编程语言都支持浮点运算,但大多数程序员很少注意它。这容易理解 ― 我们中大多数很少需要使用非整数类型。除了科学计算和偶尔的计时测试或基准测试程序,其它情况下几乎都用不着它。同样,大多数开发人员也容易忽略 java.math.BigDecimal 所提供的任意精度的小数 ― 大多数应用程序不使用它们。然而,在以整数为主的程序中有时确实会出人意料地需要表示非整型数据。例如,JDBC 使用 BigDecimal 作为 SQL DECIMAL 列的首选互换格式。

IEEE 浮点

Java 语言支持两种基本的浮点类型: floatdouble ,以及与它们对应的包装类 FloatDouble 。它们都依据 IEEE 754 标准,该标准为 32 位浮点和 64 位双精度浮点二进制小数定义了二进制标准。

IEEE 754 用科学记数法以底数为 2 的小数来表示浮点数。IEEE 浮点数用 1 位表示数字的符号,用 8 位来表示指数,用 23 位来表示尾数,即小数部分。作为有符号整数的指数可以有正负之分。小数部分用二进制(底数 2)小数来表示,这意味着最高位对应着值 ?(2 -1),第二位对应着 ?(2 -2),依此类推。对于双精度浮点数,用 11 位表示指数,52 位表示尾数。IEEE 浮点值的格式如图 1 所示。


图 1. IEEE 754 浮点数的格式
图 1. IEEE 754 浮点数的格式

因为用科学记数法可以有多种方式来表示给定数字,所以要规范化浮点数,以便用底数为 2 并且小数点左边为 1 的小数来表示,按照需要调节指数就可以得到所需的数字。所以,例如,数 1.25 可以表示为尾数为 1.01,指数为 0: (-1) 0*1.01 2*2 0

数 10.0 可以表示为尾数为 1.01,指数为 3: (-1) 0*1.01 2*2 3

特殊数字

除了编码所允许的值的标准范围(对于 float ,从 1.4e-45 到 3.4028235e+38),还有一些表示无穷大、负无穷大、 -0 和 NaN(它代表“不是一个数字”)的特殊值。这些值的存在是为了在出现错误条件(譬如算术溢出,给负数开平方根,除以 0 等)下,可以用浮点值集合中的数字来表示所产生的结果。

这些特殊的数字有一些不寻常的特征。例如, 0-0 是不同值,但在比较它们是否相等时,被认为是相等的。用一个非零数去除以无穷大的数,结果等于 0 。特殊数字 NaN 是无序的;使用 ==<> 运算符将 NaN 与其它浮点值比较时,结果为 false 。如果 f 为 NaN,则即使 (f == f) 也会得到 false 。如果想将浮点值与 NaN 进行比较,则使用 Float.isNaN() 方法。表 1 显示了无穷大和 NaN 的一些属性。

表 1. 特殊浮点值的属性

表达式 结果
Math.sqrt(-1.0) -> NaN
0.0 / 0.0 -> NaN
1.0 / 0.0 -> 无穷大
-1.0 / 0.0 -> 负无穷大
NaN + 1.0 -> NaN
无穷大 + 1.0 -> 无穷大
无穷大 + 无穷大 -> 无穷大
NaN > 1.0 -> false
NaN == 1.0 -> false
NaN < 1.0 -> false
NaN == NaN -> false
0.0 == -0.01 -> true

基本浮点类型和包装类浮点有不同的比较行为

使事情更糟的是,在基本 float 类型和包装类 Float 之间,用于比较 NaN 和 -0 的规则是不同的。对于 float 值,比较两个 NaN 值是否相等将会得到 false ,而使用 Float.equals() 来比较两个 NaN Float 对象会得到 true 。造成这种现象的原因是,如果不这样的话,就不可能将 NaN Float 对象用作 HashMap 中的键。类似的,虽然 0-0 在表示为浮点值时,被认为是相等的,但使用 Float.compareTo() 来比较作为 Float 对象的 0-0 时,会显示 -0 小于 0





回页首


浮点中的危险

由于无穷大、NaN 和 0 的特殊行为,当应用浮点数时,可能看似无害的转换和优化实际上是不正确的。例如,虽然好象 0.0-f 很明显等于 -f ,但当 f0 时,这是不正确的。还有其它类似的 gotcha,表 2 显示了其中一些 gotcha。

表 2. 无效的浮点假定

这个表达式…… 不一定等于…… 当……
0.0 - f -f f 为 0
f < g ! (f >= g) f 或 g 为 NaN
f == f true f 为 NaN
f + g - g f g 为无穷大或 NaN

舍入误差

浮点运算很少是精确的。虽然一些数字(譬如 0.5 )可以精确地表示为二进制(底数 2)小数(因为 0.5 等于 2 -1),但其它一些数字(譬如 0.1 )就不能精确的表示。因此,浮点运算可能导致舍入误差,产生的结果接近 ― 但不等于 ― 您可能希望的结果。例如,下面这个简单的计算将得到 2.600000000000001 ,而不是 2.6


 double s=0;
                        for (int i=0; i<26; i++)
                        s += 0.1;
                        System.out.println(s);
                        


类似的, .1*26 相乘所产生的结果不等于 .1 自身加 26 次所得到的结果。当将浮点数强制转换成整数时,产生的舍入误差甚至更严重,因为强制转换成整数类型会舍弃非整数部分,甚至对于那些“看上去似乎”应该得到整数值的计算,也存在此类问题。例如,下面这些语句:


 double d = 29.0 * 0.01;
                        System.out.println(d);
                        System.out.println((int) (d * 100));
                        


将得到以下输出:


 0.29
                        28
                        

这可能不是您起初所期望的。





回页首


浮点数比较指南

由于存在 NaN 的不寻常比较行为和在几乎所有浮点计算中都不可避免地会出现舍入误差,解释浮点值的比较运算符的结果比较麻烦。

最好完全避免使用浮点数比较。当然,这并不总是可能的,但您应该意识到要限制浮点数比较。如果必须比较浮点数来看它们是否相等,则应该将它们差的绝对值同一些预先选定的小正数进行比较,这样您所做的就是测试它们是否“足够接近”。(如果不知道基本的计算范围,可以使用测试“abs(a/b - 1) < epsilon”,这种方法比简单地比较两者之差要更准确)。甚至测试看一个值是比零大还是比零小也存在危险 ―“以为”会生成比零略大值的计算事实上可能由于积累的舍入误差会生成略微比零小的数字。

NaN 的无序性质使得在比较浮点数时更容易发生错误。当比较浮点数时,围绕无穷大和 NaN 问题,一种避免 gotcha 的经验法则是显式地测试值的有效性,而不是试图排除无效值。在清单 1 中,有两个可能的用于特性的 setter 的实现,该特性只能接受非负数值。第一个实现会接受 NaN,第二个不会。第二种形式比较好,因为它显式地检测了您认为有效的值的范围。


清单 1. 需要非负浮点值的较好办法和较差办法
   // Trying to test by exclusion -- this doesn't catch NaN or infinity
                        public void setFoo(float foo) {
                        if (foo < 0)
                        throw new IllegalArgumentException(Float.toString(f));
                        this.foo = foo;
                        }
                        // Testing by inclusion -- this does catch NaN
                        public void setFoo(float foo) {
                        if (foo >= 0 && foo < Float.INFINITY)
                        this.foo = foo;
                        else
                        throw new IllegalArgumentException(Float.toString(f));
                        }
                        

不要用浮点值表示精确值

一些非整数值(如几美元和几美分这样的小数)需要很精确。浮点数不是精确值,所以使用它们会导致舍入误差。因此,使用浮点数来试图表示象货币量这样的精确数量不是一个好的想法。使用浮点数来进行美元和美分计算会得到灾难性的后果。浮点数最好用来表示象测量值这类数值,这类值从一开始就不怎么精确。





回页首


用于较小数的 BigDecimal

从 JDK 1.3 起,Java 开发人员就有了另一种数值表示法来表示非整数: BigDecimalBigDecimal 是标准的类,在编译器中不需要特殊支持,它可以表示任意精度的小数,并对它们进行计算。在内部,可以用任意精度任何范围的值和一个换算因子来表示 BigDecimal ,换算因子表示左移小数点多少位,从而得到所期望范围内的值。因此,用 BigDecimal 表示的数的形式为 unscaledValue*10 -scale

用于加、减、乘和除的方法给 BigDecimal 值提供了算术运算。由于 BigDecimal 对象是不可变的,这些方法中的每一个都会产生新的 BigDecimal 对象。因此,因为创建对象的开销, BigDecimal 不适合于大量的数学计算,但设计它的目的是用来精确地表示小数。如果您正在寻找一种能精确表示如货币量这样的数值,则 BigDecimal 可以很好地胜任该任务。

所有的 equals 方法都不能真正测试相等

如浮点类型一样, BigDecimal 也有一些令人奇怪的行为。尤其在使用 equals() 方法来检测数值之间是否相等时要小心。 equals() 方法认为,两个表示同一个数但换算值不同(例如, 100.00100.000 )的 BigDecimal 值是不相等的。然而, compareTo() 方法会认为这两个数是相等的,所以在从数值上比较两个 BigDecimal 值时,应该使用 compareTo() 而不是 equals()

另外还有一些情形,任意精度的小数运算仍不能表示精确结果。例如, 1 除以 9 会产生无限循环的小数 .111111... 。出于这个原因,在进行除法运算时, BigDecimal 可以让您显式地控制舍入。 movePointLeft() 方法支持 10 的幂次方的精确除法。

使用 BigDecimal 作为互换类型

SQL-92 包括 DECIMAL 数据类型,它是用于表示定点小数的精确数字类型,它可以对小数进行基本的算术运算。一些 SQL 语言喜欢称此类型为 NUMERIC 类型,其它一些 SQL 语言则引入了 MONEY 数据类型,MONEY 数据类型被定义为小数点右侧带有两位的小数。

如果希望将数字存储到数据库中的 DECIMAL 字段,或从 DECIMAL 字段检索值,则如何确保精确地转换该数字?您可能不希望使用由 JDBC PreparedStatementResultSet 类所提供的 setFloat()getFloat() 方法,因为浮点数与小数之间的转换可能会丧失精确性。相反,请使用 PreparedStatementResultSetsetBigDecimal()getBigDecimal() 方法。

对于 BigDecimal ,有几个可用的构造函数。其中一个构造函数以双精度浮点数作为输入,另一个以整数和换算因子作为输入,还有一个以小数的 String 表示作为输入。要小心使用 BigDecimal(double) 构造函数,因为如果不了解它,会在计算过程中产生舍入误差。请使用基于整数或 String 的构造函数。

构造 BigDecimal 数

对于 BigDecimal ,有几个可用的构造函数。其中一个构造函数以双精度浮点数作为输入,另一个以整数和换算因子作为输入,还有一个以小数的 String 表示作为输入。要小心使用 BigDecimal(double) 构造函数,因为如果不了解它,会在计算过程中产生舍入误差。请使用基于整数或 String 的构造函数。

如果使用 BigDecimal(double) 构造函数不恰当,在传递给 JDBC setBigDecimal() 方法时,会造成似乎很奇怪的 JDBC 驱动程序中的异常。例如,考虑以下 JDBC 代码,该代码希望将数字 0.01 存储到小数字段:

 PreparedStatement ps =
                        connection.prepareStatement("INSERT INTO Foo SET name=?, value=?");
                        ps.setString(1, "penny");
                        ps.setBigDecimal(2, new BigDecimal(0.01));
                        ps.executeUpdate();
                        

在执行这段似乎无害的代码时会抛出一些令人迷惑不解的异常(这取决于具体的 JDBC 驱动程序),因为 0.01 的双精度近似值会导致大的换算值,这可能会使 JDBC 驱动程序或数据库感到迷惑。JDBC 驱动程序会产生异常,但可能不会说明代码实际上错在哪里,除非意识到二进制浮点数的局限性。相反,使用 BigDecimal("0.01")BigDecimal(1, 2) 构造 BigDecimal 来避免这类问题,因为这两种方法都可以精确地表示小数。





回页首


结束语

在 Java 程序中使用浮点数和小数充满着陷阱。浮点数和小数不象整数一样“循规蹈矩”,不能假定浮点计算一定产生整型或精确的结果,虽然它们的确“应该”那样做。最好将浮点运算保留用作计算本来就不精确的数值,譬如测量。如果需要表示定点数(譬如,几美元和几美分),则使用 BigDecimal



参考资料



关于作者

 

Brian Goetz 是一位软件顾问,在过去的 15 年里一直是一位专业软件开发人员。他是 Quiotix的首席顾问,该公司是位于加利福尼亚 Los Altos 的软件开发和咨询公司。请在业界流行的出版物上查阅 Brian 已发表的和即将发表的文章。可以通过 brian@quiotix.com与 Brian 联系。

posted @ 2010-07-09 17:05 favorer 阅读(178) | 评论 (0)编辑 收藏

做程序员要遵循的几个基本原则!(袁红岗)

姓名:袁红岗
职业:金蝶中间件CTO
年龄:猜
位置:中国
个性介绍:具有敏锐的技术触觉,有多年的软件开发经验,对应用软件的技术发展趋势有着准确的判断力,是国内第一个J2EE应用服务器的缔造者,也是国内业界深入理解J2EE技术体系的程序员和标志性人物。

   

        不知不觉做软件已经做了十年,有成功的喜悦,也有失败的痛苦,但总不敢称自己是高手,因为和我心目中真正的高手们比起来,还差的太远。世界上并没有成为高手的捷径,但一些基本原则是可以遵循的。

  1. 扎实的基础。数据结构、离散数学、编译原理,这些是所有计算机科学的基础,如果不掌握他们,很难写出高水平的程序。据我的观察,学计算机专业的人比学其他专业的人更能写出高质量的软件。程序人人都会写,但当你发现写到一定程度很难再提高的时候,就应该想想是不是要回过头来学学这些最基本的理论。不要一开始就去学OOP,即使你再精通OOP,遇到一些基本算法的时候可能也会束手无策。

  2. 丰富的想象力。不要拘泥于固定的思维方式,遇到问题的时候要多想几种解决问题的方案,试试别人从没想过的方法。丰富的想象力是建立在丰富的知识的基础上,除计算机以外,多涉猎其他的学科,比如天文、物理、数学等等。另外,多看科幻电影也是一个很好的途径。

  3. 最简单的是最好的。这也许是所有科学都遵循的一条准则,如此复杂的质能互换原理在爱因斯坦眼里不过是一个简单得不能再简单的公式:E=mc2。简单的方法更容易被人理解,更容易实现,也更容易维护。遇到问题时要优先考虑最简单的方案,只有简单方案不能满足要求时再考虑复杂的方案。

  4. 不钻牛角尖。当你遇到障碍的时候,不妨暂时远离电脑,看看窗外的风景,听听轻音乐,和朋友聊聊天。当我遇到难题的时候会去玩游戏,而且是那种极暴力的打斗类游戏,当负责游戏的那部分大脑细胞极度亢奋的时候,负责编程的那部分大脑细胞就得到了充分的休息。当重新开始工作的时候,我会发现那些难题现在竟然可以迎刃而解。

  5. 对答案的渴求。人类自然科学的发展史就是一个渴求得到答案的过程,即使只能知道答案的一小部分也值得我们去付出。只要你坚定信念,一定要找到问题的答案,你才会付出精力去探索,即使最后没有得到答案,在过程中你也会学到很多东西。

  6. 多与别人交流。三人行必有我师,也许在一次和别人不经意的谈话中,就可以迸出灵感的火花。多上上网,看看别人对同一问题的看法,会给你很大的启发。

  7. 良好的编程风格。注意养成良好的习惯,代码的缩进编排,变量的命名规则要始终保持一致。大家都知道如何排除代码中错误,却往往忽视了对注释的排错。注释是程序的一个重要组成部分,它可以使你的代码更容易理解,而如果代码已经清楚地表达了你的思想,就不必再加注释了,如果注释和代码不一致,那就更加糟糕。

  8. 韧性和毅力。这也许是"高手"和一般程序员最大的区别。A good programming is 99 weat and 1 ffee。高手们并不是天才,他们是在无数个日日夜夜中磨练出来的。成功能给我们带来无比的喜悦,但过程却是无比的枯燥乏味。你不妨做个测试,找个10000以内的素数表,把它们全都抄下来,然后再检查三遍,如果能够不间断地完成这一工作,你就可以满足这一条。
 
  这些是我这几年程序员生涯的一点体会,希望能够给大家有所帮助。

posted @ 2010-07-09 16:39 favorer 阅读(382) | 评论 (0)编辑 收藏

与Java相关的四十个名字

转自:http://java.ccidnet.com/art/3737/20040802/512335_1.html

十大事件

1990-1994:Java缘起
文/孟岩

Larry Wall说,优秀程序员应有的三个特点:懒惰、急躁和傲慢。Java就是诞生在一群懒惰、急躁而傲慢的程序天才之中。
1990年12月,Sun的工程师Patrick Naughton被当时糟糕的Sun C++工具折磨的快疯了。他大声抱怨,并威胁要离开Sun转投当时在Steve Jobs领导之下的NeXT公司。领导层为了留住他,给他一个机会,启动了一个叫做Stealth(秘密行动)的项目。随着James Gosling等人的加入,这个项目更名为Green。其目标是使用C++为嵌入式设备开发一种新的基础平台技术,James Gosling本人负责开发一个SGML编辑器。正如人们事后分析的那样,这位天才的程序员太懒惰,所以没有把C++学好,开发中碰了一头包;太急躁——所以不愿意停下来读读Scott Meyers的新书《Effective C++》;太傲慢——所以轻易地决定开发一中新的编程语言。他把这种语言命名为C++++--,意思是C++“加上一些好东西,减去一些坏东西”。显然这个糟糕的名字不可能长命百岁,很快这种颇受同伴喜爱的小语言被命名为Oak。
到了1992年9月,Oak语言连同Green OS和一些应用程序一起发布在称做Start 7的小设备上,从而使之有了第一次精彩的亮相。随后,Sun开了一家名为FirstPerson的公司,整个团队被转移到这家公司里研发机顶盒,以投标时代华纳公司的一个项目。这帮天才被技术狂热所鼓舞,开发出了一个高交互性的设备,结果没想到时代华纳公司和有线电视服务商并不愿意用户拥有那么大的控制权,从而在竞标之战中败给了SGI。Oak的锋芒之锐,竟然把客户都给吓懵了。Sun沮丧地关闭了FirstPerson,召回了整个团队。事实证明,传统行业中那些脑满肥肠的保守主义者是腐朽没落的。回去!回到激情澎湃的IT产业,抓住互联网的大潮,这才是出路!1994年,Oak被命名为Java,针对互联网的新一轮开发如火如荼,一切已经就绪,熔岩在地下奔流,火山即将喷发。


1995: Java香浓世界
文/马伟

1995年,Sun正式对外公布了Java,并且发布了JDK 1.0。这种外形酷似C++,却包含一颗Smalltalk般纯洁的面向对象之心的全新程序设计语言及其平台,几乎在一夜之间就成为软件产业的新宠儿。Java当时仅仅被用来为网站制作一些动态应用,诸如动画图片之类,但这仍然引起了很多Web开发者们的注意,他们非常渴望有一种安全的语言,可以在静态的HTML网页上制作动画图片。Sun最终把Java集成到NetScape浏览器。同时因为它具有“只写一次,随处运行”的特性,而引起了很多开发者的注意,他们可以再也不用为了使程序能够在不同型号的硬件上运行而耗费大量的时间来编译代码了。
当时的Web浏览器的出现也为Java的出现起到了很好的推动作用,通过Java和Web浏览器的结合,人们似乎看到了什么,有人甚至预言PC将在一两年内退出历史的舞台,取而代之的是基于Java的浏览器应用程序,通过网络计算设备来进行应用。Java的出现为当时的软件产业带来了无限的遐想。


1996:Java大跃进,盟主地位就此定
文/马伟

SUN在1996年一开始首先成立了JavaSoft组织,并在1月23日正式发布自己的Java 1.0,作为20世纪业界出现的最重要的技术之一,Java引起了编程世界的革命。直到现在,Java仍然是互联网上最流行的语言。
在Sun正式发布Java 1.0之后,Java这门新生的语言就拥有了自己的会议——JavaOne,这次会议初试啼音就吸引了600多名参与者。除了拥有这么多的积极参与者来进行Java的开发之外,各大知名公司也纷纷向Sun申请Java的许可。一时间,NetScape、惠普、IBM、Oralce、Sybase甚至当时刚推出Windows 95的微软都是Java的追随者。
Java的应用就像是世界上的顶级玩家们组成的一个公开联盟,告诉全世界我们大家就是都在用着Java。也正是因为如此,Java也找到了自己的归宿。现在的J2EE已经成为中大型企业级应用的标准,成为承接数据库和Web之间的一个重要桥梁。
当年Java的机会实在太多了,以至于很难知道到底该做什么。最终Java在应用服务器市场获得了难以取代的地位,也确定了J2EE的发展方向,并且仍将延续下去。


1997-2001:  微软与Sun的Java官司
文/孟岩

Java诞生的1995年,正是微软在软件产业地位达到巅峰的时代,Windows 95发布时的风光场面给人们留下的深刻印象至今难忘。尽管如此,作为最卓越的技术领袖,比尔?盖茨仍然敏锐地注意到Java。当他了解了Java的一些细节之后,给予了这样的评价:“Java是很长时间以来最优秀的程序设计语言。”基于此,微软于1996年3月申请并获得了Java许可证。微软对于Java的这一热情态度在当时大大提高了人们对Java的兴趣和信心,但也有不少人担心微软会依靠自己强大的影响力在标准之外另立标准,从而破坏Java的纯洁性。
果然,从1997年发布Visual J++的第一个版本开始,微软就开始在Java中掺入自己的私有扩展。这毫无疑问引起Sun的高度重视。1997年10月,Sun向美国加州地方法院起诉微软公司违反两公司就微软使用Java技术所签定的合同,指控微软公司在自己的Java产品中做了“不恰当的修改”,违反了合同中承诺向用户提供Java兼容产品的条款。这一官司旷日持久,直到2001年1月双方达成和解,微软将继续提供采用Sun开发的Java技术的现有产品(包括测试版)。不过,Sun有限制地仅对包括Java 1.1.4的微软产品提供许可。到了2001年7月,微软公布新版的Windows XP将不再支持Sun的JVM,并且推出了.NET平台与Java分庭抗礼。
现在回过头去看,当时的这一场官司对Java世界产生了深远的影响。如果没有这一场官司,也许很多Java程序员都在使用Visual J++,基于WFC开发Windows客户端程序,同时不得不面对被两个不同的事实标准所分裂的Java世界。


1998:Java 2平台发布
文/陶文

1998年,Java 2平台正式发布。经过了三年时间的发展、热热闹闹的攻关宣传、红红火火的众厂商的热情参与,Sun终于知道Java适合干什么了。对比Java刚发明时的技术定位,与Java的戏剧性触“网”的那段历史,Java 2平台的发布可真算得上是有的放矢了。根据官方的文档,Java 2是Sun意识到“one size doesn’t fit all”之后,把最初的Java技术打包成三个版本的产物,也就是著名的J2ME、J2SE、J2EE。
之所以说Java自从Java 2平台发布之后,进入了现代。那是因为之前的历史怎么看来都和现在程序员日常开发使用的技术无什么关系,比如Applet,已经很少有人使用了。Java 2之后的历史就不一样了,至少人们在推崇轻量级开发,猛批EJB时还不时会引用J2EE这个词是如何诞生的。而Java 2的三大版本中,除了J2EE得到了长足发展和广泛使用之外,J2ME也在手机市场上取得了遍地开花的结果。相较之下,J2SE难免落寞,只剩SWT这个血统不纯的家伙在Rich Client回归的时代吸引着人们的眼球了。无论今天看来当时的Java 2有多么的不成熟,至少经过市场和时间的检验,Java 2规划出来的三大方向把Java技术指向了光明的方向是勿庸置疑的。


1998:JCP成立并正式运作,
Java开源社群开始蓬勃发展
文/黄海波

1998年,JCP组织成立,并且开始把握Java的发展方向。JCP组织的开放性,不但使得所有对Java感兴趣的商业公司可以参与Java的发展,更重要的是JCP允许个人、非盈利组织、学校等加入,这就给Java带来了巨大的活力。随之兴起的Java开源运动的最大贡献是实现和鼓励了知识共享,在众多热情的开源程序员们的努力和分享下,很多原先只被商业公司掌握的技术、思想和产品可以被所有需要的开发人员免费或者以较低的价格获得使用权, 并通过开放源代码更容易的获得反馈和改进意见从而进一步演化发展。我们知道,所谓知识不是孤立发展认知,而是人们的经验,认识是思考交流和积累的产物。而开源运动所带来的开放、反馈、交流的风气正是符合人类社会知识形成和发展的规律。
开源运动起源于西方的发达国家,有其现实背景和文化根源。1990年代可以说是IT产业的一个黄金时代。信息时代的兴起对IT人员,特别是软件人员有着巨大的需求。而软件开发又是一种类似艺术创作的脑力活动,和所有的艺术家、作家们一样,在作品打上自己的印记并流传在世界上是每一个创作人员的梦想。互联网时代下的高收入的舒适生活,早九晚五的编写公司的代码并不能满足很多有激情的软件开发人员的梦想,再加上西方传统的基督教文化中十分推崇的分享和交流,开源的出现和兴起也就水到渠成了。今天,开源运动已经不仅仅是一些个人天才程序员们的游乐园地,而是发展成为一项开源软件产业。


1998:WebLogic打开J2EE的魔匣
文/霍泰稳

Java语言的出现使得互联网络有了良好的交互性能,但这些很“酷”的技术仅被人们认为是一些小花招,它还无法消除企业级用户对它的怀疑。1998年,BEA公司宣布收购WebLogic公司,并接着推出由Sun公司第一个授权使用J2EE许可证的WebLogic Server应用服务器,这个Java版的AppServer一推出就引起业界极大的兴趣。WebLoigc Server以其对标准的支持、强悍的运算能力和安全的架构设计等特性也很快征服了那些怀疑J2EE应用的人们。推出市场后不到一年,WebLogic Server就成为业内第一Java应用服务器。
这里我们援引一些当时著名咨询公司的调查数据来说明问题,“在IDC的报告中,BEA在应用服务器和交易服务器领域市场份额第一;在Gartner的报告中,BEA WebLogic Server拥有业内最广泛的EJB应用安装基础;在Giga Group的报告中,BEA WebLogic Server市场份额占32%”。
因为应用服务器市场极大的发展潜力,在WebLogic Server之后,其它的很多公司也推出了自己的AppServer,如IBM的WebSphere、Sun公司的iPlanet等,逐渐地应用服务器取代了传统意义上的各类中间件,成为企业应用的基础平台。应用服务器的出现使得Java有了真正意义上的发展。
 

2002-2004: Sun与微软的法律碰撞最终以喜剧收场
文/恶魔

2003年4月2 日,Sun与微软达成16亿美元的法律和解。如果不是晚了一天,许多人会以为这是一个在4月1日愚人节开的玩笑。尽管当时所有人都像是看到“太阳从西边出来了”那样张大了嘴巴,但这的确是事实。
根据两家公司达成的版权协议,双方会为采用对方的技术而支付专利费用,微软向Sun提前支付3.5亿美元使用费,Sun则承诺,如果Sun集成微软的某些技术,也会向微软付款。
毫无疑问,“私下了结”的方式对双方而言都是最好的结果。就在协议签署的当天,在美国旧金山由Sun和微软为“抛弃十年恩怨、携手合作“举行的新闻发布会上,尽管比尔?盖茨没有到场,但这并没有防碍现场看起来异常轻松的气氛。麦克尼利和鲍尔默各自穿了一件密歇根州底特律“Red Wings”曲棍球队的运动服,并谈及了一起在哈佛大学读书的经历,麦克尼利还说:“当时我们两人是非常要好的朋友,当然我们也有吵架的时候。”人与人当然可能成为终生的知己,但是公司与公司之间有的只能是利益上的分分合合。


2000-2004: JBoss和Eclipse
——Java开源软件的王者
文/莫映

Java和开源几乎就是天生的一对,这可以从无比兴盛繁荣的Java开源软件社区得到佐证。目前最有影响力的Java开源软件项目,要数JBoss和Eclipse。可以说,几乎所有的Java开发人员都获多或少的听到过或接触和使用过它们。前者是目前最优秀、应用最为广泛的企业级开源J2EE应用服务器,后者是功能完全可以替代商业产品的Java IDE。二者的覆盖功能之全、支持工具之广、子项目之多,几乎可以仅凭借它俩来完成企业应用的开发构建到部署实施的全过程,而软件开发者和客户也都可以最大程度上享受高质量,高可靠Java开源软件所带来的低成本优势。
JBoss和Eclipse的巨大成功,几乎令各自领域的商用竞争者抓狂,其中BEA的WebLogic和IBM的WebSphere在商业利润上受到JBoss的巨大侵蚀,而Borland的JBuilder、JetBrains的IDEA等诸多优秀的商用开发工具也不得不面对Eclipse独大的现实。JBoss的CEO兼创始人 Marc Fleury曾直言不讳地表示,希望占据市场主导地位。“我们希望打败IBM,成为中间件领域里最大的厂商。”JBoss在4.0以前还只是以一个Group存在,盈利手段主要靠服务和销售文档。但在最近,JBoss已经发展成为一个有限公司,并吸纳多家风险投资,专注于获取利润为目标之一的第二代开源软件模式(JBoss自己称为“Professional Open Source”)的创新和运营。这区别于以理论研究为爱好的学院型开源或大公司为基础的非盈利组织开源,如Linux和Apache。当然JBoss的这种运营方式势必会导致更多的代码控制和专有修改权,但按JBoss的说法是这样更能获得企业客户的信赖。JBoss的这种模式是否能获得成功还要我们拭目以待。
不管JBoss和Eclipse的未来发展如何,JBoss和Eclipse的成功已经让我们看到了Java开源软件的威力,祝愿它们一路走好。


2004:Java 5.0
文/莫映

2004年9月30日,代号为“Tiger”,研发历时近三年的J2SE 5.0发布正式版本,这是Java平台历来发布版本中改动面波及最大的一次。
纵观Tiger,“Ease of development”是其核心主题,这一点着重体现于语言特性上的改进,这在很大程度上,简化了开发人员日常的编程任务,以往一些琐碎的手工劳动都代之以轻松自然,而又安全可靠的自动化实现。其中的注解功能,以及随之而来的声明式编程,还对构筑于J2SE 5.0之上的J2EE 5.0产生了巨大影响。尽管Tiger在语言特性上做了很大的动作,但作为Java技术的基础支撑,这些改动都是深思熟虑的结果。
Tiger发布至今也有大半年了,那么Sun又是如何规划J2SE的未来蓝图的呢?据悉,J2SE的下两个版本分别是代号为“Mustang”的J2SE 6.0和代号为“Dolphin”的J2SE 7.0,预计Mustang将于明年发布。在吸取了Tiger研发周期过长的教训之后,Sun副总裁Graham Hamilton表示,Mustang的发布周期将不会那么长。并且,Sun还将“Becoming more open” 作为Mustang的主题之一。未来JCP对Java技术的影响将会愈加深入,而整个研发过程也将会愈加透明。Mustang在正式发布前的内部版本也会陆续见诸于众,如此,广大Java开发者便可以更加及时的了解到Java发展的最新情况。在语言层面上的扩展依然会比较谨慎,比如像AOP这样的当下热门技术,依然不太可能会见诸其中。据Hamilton所言,一个有可能被引入的语法特性被称作“friends”import机制,它将使由多个包组成的大型项目变得易于管理。

 

十大人物

James Gosling : Java之父
文/陶文

作为Java之父,James Gosling的名字可谓是耳熟能详。当人们评论一种编程语言时,总喜欢捎带着把下蛋的母鸡一起带上。Java做为中国的编程语言学习者餐桌上有限的那么几样餐点中的流行款式,自然是让James Gosling风光不已。虽然James Gosling现在已经不是领导Java发展潮流的领军人物了,做为Sun的开发者产品组的CTO,怎么算来也是身居高位了,俗事缠身吧,但是这并不妨碍其对于Java一如既往的爱护,表达着各式各样鲜明的观点,引发一场又一场的争论。
James Gosling是很爱Java的——是啊,哪有当父母的不爱自己的孩子的呢。James Gosling也是很爱Sun的——是啊,哪有当领导的不爱自己的公司的呢。于是我们在批评.NET的安全性的队伍前头,在褒扬Java性能的队伍前头,在抨击SWT开倒车的队伍前头,在给NetBeans大唱赞歌的队伍前头,我们都看到了James Gosling的身影。无论对错、偏见或者固执,至少说明了Gosling的鲜明个性丝毫没有受到年龄的影响。也许也只有这种天才而偏执的人物才能创造出Java这般伟大的语言来吧。
 

Bill Joy : 软件业的爱迪生
文/徐昊

Joy生于1954年,1982年与Vinod Khosla, Scott McNealy和Andy Bechtolsheim一起创建了Sun Microsystems,并从那时起担任首席科学家,直到2003年离开。他是一位令人崇敬的软件天才,他在软件和硬件的历史上留下了无数令人仰止的传奇。
在上个世纪80年代早期,DARPA与BBN达成协议,准备将Vinton Cerf和Bob Kahn设计的TCP/IP协议添加到Berkeley UNIX中。Bill Joy被委派来完成这项任务,然而他却拒绝将BBN的TCP/IP协议栈添加到BSD中,因为在他的眼中BBN的TCP/IP实现还远不够好,于是他就写了一个高性能的TCP/IP协议栈。John Gage回忆道,“BBN和DARPA签署了巨额合同来实现TCP/IP协议,然而他们的员工所编写的代码远没有一个研究生所做的好。于是他们邀请Bill Joy参加他们的一个会议,这位研究生穿着一件T-Shirt就出现了,他们询问他,‘你是如何做到的呢?’Bill回答说,‘这是非常简单的一件事,你读一下协议然后就可以编码了’”。除了TCP/IP协议,基于分页的虚拟内存系统最早也是由Bill Joy添加到Berkeley UNIX内核当中的。同时他还是vi、csh、早期Pascal编译器的作者。
关于Bill Joy惊人的软件才能流传最广的一个传奇是,据说他在上研究生的时候,想看看自己能不能写一个操作系统出来,于是就在三天里写了一个非常简陋,但是可以使用的Unix系统, 传说就是BSD的前身。虽然如此夸张的才情令人难以置信,但是考虑到主角是Bill Joy,还是有一定的可信度的。Bill Joy硕士毕业之后,决定到工业界发展,于是就到了当时只有一间办公室的Sun, 他作为主要设计者参与了SPARC微处理器的设计,负责设计最为关键的一部分电路。这样兼精软硬件的天才实在是让人不得不佩服啊。1995年,Sun发布了轰动世界的Java语言。当然,Bill Joy对Java也作出了不少的贡献,首先是JINI——一种针对分布式服务的基础连接技术。任何可以内嵌JVM的电子设备都可以通过JINI相互连接;JXTA是基于Java的P2P协议,允许互联网上的软件进行点对点交流和协作。
这个其貌不扬的瘦高个,有着凌乱的亚麻色头发,被《财富》杂志誉为“网络时代的爱迪生”的技术狂人,在短短的二十年间,创造了无数令人心动的软件。在MIT的BBS上曾有一个帖子,说微软电话面试有一道题,问“Who do you think is the best coder, and why?”虽然回复的帖子中大家都声明列举的best coder排名不分先后,然而大多数人仍把Bill Joy列在第一位,或许可以从一个侧面验证Bill Joy在广大Programmer心目中的地位吧。


Joshua Bloch :  Java 2 元勋
文/莫映

早在1996年,适逢Java刚刚崭露头角,年内好事连连。先是1月份发布JDK 1.0,然后是5月底在旧金山召开首届JavaOne大会,年末又是JDK 1.1紧跟其后。正是在Java技术如火如荼、大展拳脚的背景之下,Joshua Bloch来到了Sun,开始了他带领Java社区步入“迦南美地”的漫长历程。
很快,他被从安全组调入核心平台组,从事底层API设计。至此以后,每逢JDK的重大版本发布,总能在其中见到Joshua的“妙笔”。JDK 1.1中的java.math、1.4中的assertions,还有大家所熟识的Collections Framework皆是Joshua一手打造。其中的Collections Framework还获得了当年的Jolt大奖。到了J2SE 5.0研发阶段,身为平台组构架师的Joshua接掌了Tiger大旗,其核心地位已然无人可以替代。作为Tiger的代言人和领路人,没有谁比Joshua更清楚Tiger。相信大家一定还记得Joshua当年仿效英国诗人William Blake所做的咏Tiger诗八首,优雅的笔调,透出大师深厚底蕴的同时,也道出了Tiger的几大重要特性,这些特性是自JDK 1.1引入Inner Class以来,Java最大的语法改进。
Java风雨十年,从JDK 1.1到J2SE 5.0,Joshua实在功不可没。难怪有人戏言,假如将James Gosling比作Java之父,那么Joshua就是一手将Java “哺育”成人的Java之母。Joshua对Java的贡献还不止于JDK,提起他的大作《Effective Java》(Addison Wesley, 2001),相信Java粉丝们一定耳熟能详。该书荣膺2002年度Jolt大奖,且备受James Gosling推崇。书中57条颇具实用价值的经验规则,来自Joshua多年来在JDK开发工作中,尤其是Collections Framework设计中的实践心得,各个有理有据,剖析深入,也足见其深厚功力。该书对Java社群的影响,犹如C++社群中的《Effective C++》。Joshua对JCP的贡献也不小。他是JSR201和JSR175的领导者,前者包含了Tiger四大语言特性,后者则为Java提供了元数据支持。此外,他还是JSR166的发起人之一(该JSR由Doug Lea领导),并且是许多其他JSR的参与者。Joshua目前是JCP为数不多的几个执行委员会成员之一。
Joshua Bloch给人的印象是谦逊平和,行事低调而不喜抛头露面,一个典型的技术人员和实干家。不过即便如此,也丝毫不会减弱他对Java技术的卓越贡献和对Java社区的绝对影响力。有人说,如果他能更彰显一些,就很有可能成为Java开发者中的领军人物,就有如Don Box之于微软社群。
2004年7月初,就在Tiger发布在即之时,就在Jusha Bloch刚刚荣获Sun“杰出工程师(Distinguished Engineer)”的称号之时,他突然离开Sun而去了正值发展态势迅猛的Google。当他离开Sun的消息在TSS发布之后,众多拥趸表达了怀念与不舍之情。一年过去了,我们还没有获知Joshua的任何近闻,似乎又是他行事低调的一贯作风所致,不知他在Google状况如何。希望Joshua依然能继续“摩西未尽的事业”,以他的影响力推动Java社群继续前行。据称,《Effective Java》的下一版会加入Java 5.0的部分,让我们翘首以待吧。


Bruce Eckel : 功勋卓著的机会主义分子
文/孟岩

Bruce Eckel原本是一位普通的汇编程序员。不知道是什么因缘际会,他转行去写计算机技术图书,却在此大红大紫。他成功的秘诀不外乎两点:超人的表达能力和捕捉机会的能力。他最早的一本书是1990年代初期的《C++ Inside & Out》,随后,在1995年他写出了改变自己命运的《Thinking in C++》。如果说这本书充分表现了他作为优秀技术作家的一面,那么随后他写作《Thinking in Java》并因此步入顶级技术作家行列,则体现了他作为优秀的机会主义分子善于捕捉机会的另一面。写作中擅长举浅显直接的小例子来说明问题,语言生动,娓娓道来,特别适合于缺乏实践经验的初学者。因此《Thinking in Java》俨然成为天字第一号的Java教科书,对Java的普及与发展发挥着不可忽略的作用。不过公允地说,Bruce Eckel的书欠深刻。比如在“Thinking in…”系列中对设计模式的解说就有失大师水准。这一方面是因为书的定位非常清晰,另一方面也是因为Bruce太过分心赶潮流,未能深入之故。TIJ之后,他预言Python将火,就匆匆跑去写了半本《Thinking in Python》。后来Python并未如期而旺,于是他也就把书稿撂在那里不过问了,机会主义的一面暴露无遗。我们也可以善意的猜测一下,他的下一个投机对象会是什么呢?Ruby?.NET?MDA?总之,是什么我都不奇怪。


Rickard Oberg :J2EE奇才
文/熊节

Oberg的作品很多,流行的代码生成工具XDoclet和MVC框架WebWork都出自他的手笔。这两个框架有一个共同的特点,即它们的功能虽然简单,但设计都非常优雅灵活,能够很方便地扩展新功能甚至移植到新环境下使用。优雅的设计源自Oberg的过人才华,简单的功能则折射出他玩世不恭的人生态度。正是这两种特质的融合,才造就了这个不世出的奇才。
1999年,JDK 1.3发布,其中带来了一个重要的新特性:动态代理(Dynamic Proxy)。当所有人都还在对这项新技术的用途感到迷惑时,Oberg发现用它便可以轻松攻克EJB容器实现中的一些难关。这一发现的产物就是一本《Mastering RMI》,以及大名鼎鼎的JBoss应用服务器。但Oberg很快又让世人见识了他的玩世不恭。由于和总经理Marc Fleury在经营理念上不合,Oberg抱怨“法国的天空总让我感到压抑”,甩手离开了自己一手打造的JBoss。此后的几年里,他和老友Hani Suleiman不断地对JBoss的“专业开源”模式和Marc Fleury的商人味道冷嘲热讽,让众人为他的孩子气扼腕叹息。
2002年10月,微软推出Petstore示例应用的.NET版本,并宣称其性能比Java Petstore高出数倍。正是Oberg深入分析这个示例应用的源代码,在第一时间指出它大量运用了SQL Server专有的特性,性能对比根本不具参考价值。后来Oberg又先后关注了AOP和IoC容器,两者都成为了J2EE架构的新宠。
 

Doug Lea : 世界上对Java影响力最大的个人
文/KIT

如果IT的历史,是以人为主体串接起来的话,那么肯定少不了Doug Lea。这个鼻梁挂着眼镜,留着德王威廉二世的胡子,脸上永远挂着谦逊腼腆笑容,服务于纽约州立大学Oswego分校计算器科学系的老大爷。
说他是这个世界上对Java影响力最大的个人,一点也不为过。因为两次Java历史上的大变革,他都间接或直接的扮演了举足轻重的脚色。一次是由JDK 1.1到JDK 1.2,JDK1.2很重要的一项新创举就是Collections,其Collection的概念可以说承袭自Doug Lea于1995年发布的第一个被广泛应用的collections;一次是2004年所推出的Tiger。Tiger广纳了15项JSRs(Java Specification Requests)的语法及标准,其中一项便是JSR-166。JSR-166是来自于Doug编写的util.concurrent包。
值得一提的是: Doug Lea也是JCP (Java小区项目)中的一员。
Doug是一个无私的人,他深知分享知识和分享苹果是不一样的,苹果会越分越少,而自己的知识并不会因为给了别人就减少了,知识的分享更能激荡出不一样的火花。《Effective JAVA》这本Java经典之作的作者Joshua Blosh便在书中特别感谢Doug是此书中许多构想的共鸣板,感谢Doug大方分享丰富而又宝贵的知识。这位并发编程的大师级人物的下一步,将会带给Java怎样的冲击,不禁令人屏息以待。


Scott McNealy :SUN十年来的掌舵者
文/KIT

McNealy,Sun的CEO、总裁兼董事长。他曾经狂傲的说:“摧毁微软是我们每个人的任务。”这位英勇的硅谷英雄,似乎带头起义,试图组织一个反微软阵线联盟,以对抗微软这股庞大的托拉斯恶势力。他时常口出惊人之语,在公开场合大肆的批评微软,并曾经说微软的.NET是.NOT。
Scott McNealy先后毕业于哈佛大学及史丹佛大学,分别持有经济学学士学位及企管硕士。1982年MBA毕业的他和三个同学共同合伙创建了Sun,并于1984年成为Sun的执行官。“要么吞了别人,不然就被别人吞了”是Scott McNealy的名言录之一。他擅长以信念带动员工,鼓舞士气。极富自信的他,对于认定的事,总是坚持自己的想法,因此有人形容他是一个刚愎自用的决策者。
身为Sun这艘船的掌舵者,Scott McNealy能够看多远,Sun就能走多远。Scott McNealy认为将来软件界是一个只有服务,没有产品的世代。他希望打造出Sun不是一个纯靠硬件赚钱的公司。从Open Source到Open Solaris,Sun希望可以成为提供整合性解决方案的服务厂商。Solaris 10 + UltraSPARC是否可以像Scott McNealy希望的是下一匹世纪黑马呢?Sun是否能以股价来证明华尔街分析师及普罗大众的诽短流长?Scott McNealy是否能带领着Sun成为继微软之后的下一个巨人,一场场IT界的争霸战值得我们拭目以待。


Rod Johnson : 用一本书改变了Java世界的人
文/ 刘铁锋

Rod在悉尼大学不仅获得了计算机学位,同时还获得了音乐学位。更令人吃惊的是在回到软件开发领域之前,他还获得了音乐学的博士学位。有着相当丰富的C/C++技术背景的Rod早在1996年就开始了对Java服务器端技术的研究。他是一个在保险、电子商务和金融行业有着丰富经验的技术顾问,同时也是JSR-154(Servlet 2.4)和JDO 2.0的规范专家、JCP的积极成员。
真正引起了人们的注意的,是在2002年Rod Johnson根据多年经验撰写的《Expert o­ne-on-One J2EE Design and Development》。其中对正统J2EE架构的臃肿、低效的质疑,引发了人们对正统J2EE的反思。这本书也体现了Rod Johnson对技术的态度,技术的选择应该基于实证或是自身的经验,而不是任何形式的偶像崇拜或者门户之见。正是这本书真正地改变了Java世界。基于这本书的代码,Rod Johnson创建了轻量级的容器Spring。Spring的出现,使得正统J2EE架构一统天下的局面被打破。基于Struts+Hibernate+Spring的J2EE架构也逐渐得到人们的认可,甚至在大型的项目架构中也逐渐开始应用。
Rod Johnson的新作《Expert o­ne-on-one J2EE Development without JEB》则更让人吃惊,单单“Without EJB”一词就会让大多数J2EE架构师大跌眼镜了。不过Rod Johnson可能仅仅是想通过“Without EJB”一词表明应该放开门户之见。这也是Rod Johnson一贯的作风,。也许正是这种思想,促使得Rod Johnson创建了Spring,真正改变了Java世界。

 

Alan Kay :Java的精神先锋
文/徐昊

Sun的官方Java教材中有一句话,说Java是“C++的语法与Smalltalk语义的结合”。而Smalltalk的创造者就是Alan Kay。
Alan Kay于1970年加入Xerox公司的Palo Alto研究中心。早在70年代初期,Alan Kay等人开发了世界上第二个面向对象语言Smalltalk,因此,Alan Kay被誉为Smalltalk之父。2003年,Alan Key因为在面向对象程序设计上的杰出贡献,获得了有计算机界的诺贝尔奖之称的ACM Turing Award。
Alan Kay成名于Smapltalk和OOP,而Java虽然在语言上类似于C,但是在语义上非常接近Smalltalk,很多Java中的设计思想在Alan Kay的文献中找到根源,也有些人将Alan Kay尊为Java思想的先驱。不过遗憾的是似乎Alan Kay老先生对Java并不买账,反倒攻击说Java是存在致命缺陷的编程语言,Java的成功不是由于Java本身的内在价值,而是其商业化的成功。Alan Kay欣赏的是Lisp,他认为Lisp是软件的麦克斯韦方程,其中的许多想法是软件工程和计算机科学的一部分。看来拥有Alan Kay这样一位重量级的Java先驱仍是我们Java一厢情愿的单恋吧。

Kent Beck : 领导的敏捷潮
文:刘铁锋

Beck全家似乎都弥漫着技术的味道。生长在硅谷, 有着一个对无线电痴迷的祖父,以及一个电器工程师父亲。从小就引导Kent Beck成为了业余无线电爱好者。
在俄勒冈州大学读本科期间,Kent Beck就开始研究起模式。然而在他最终拿到计算机学位之前,他却是在计算机和音乐中交替学习。似乎Java大师都能够有这样的能耐,另一Java大牛Rod Johnson同样也拥有音乐学的博士学位。
Kent Beck一直倡导软件开发的模式定义。早在1993年,他就和Grady Booch(UML之父)发起了一个团队进行这个方面的研究。虽然著有了《Smalltalk Best Practice Patterns》一书,但这可能并不是Kent Beck最大的贡献。他于1996年在DaimlerChrysler启动的关于软件开发的项目,才真正地影响后来的软件开发。这次的杰作就是XP(极限编程)的方法学。
和软件开发大师Martin Fowler合著的《Planning Extreme Programming》可谓是关于XP的奠基之作。从此,一系列的作品如《Test Driven Development: By Example》,《Extreme Programming Explained: Embrace Change》让更多的人领略到了极限编程的精髓,也逐步导致了极限编程的流行。
Kent Beck的贡献远不仅如此。对于众多的Java程序员来说,他和Erich Gamma共同打造的JUnit,意义更加重大。也许正式这个简单而又强大的工具,让众多的程序员更加认可和信赖极限编程,从而引起了Java敏捷开发的狂潮吧。


 十大产品

Sun JDK :Java的基石
文/莫映

众所周知,流传于市的JDK不单Sun一家,比如IBM的JDK、BEA的JRocket、GNU的GCJ,以及如Kaffe这样的开源实现,不一而足。但是,根正苗红的Sun官方JDK一直以来都是备受瞩目的主流,它对Java社区的影响也是举足轻重。
1996年1月,Sun在成立了JavaSoft部门之后,推出了JDK 1.0,这是Sun JDK(Java Development Kit)的首个正式版本;当年12月,JDK1.1出炉。该版除了对前序版本部分特性做了改进以外,重写了AWT,采用了新的事件模型。1998年12月,JDK 1.2正式发布。此时的类库日臻完善,API已从当初的200个类发展到了1600个类。在1.2版本中引入了用100%纯Java代码写就的Swing,同时,Sun将Java更名为Java 2。
1999年,Java 技术形成了J2SE、J2EE和J2ME三大格局。Sun向世人公布了Java HotSpot性能引擎技术的研究成果。HotSpot旨在进一步改善JVM性能,提高Java ByteCode的产生品质,加快Java应用程序的执行速度。J2SE 1.3发布于2000年;2002年2月间,J2SE 1.4问世,这是有JCP参与以来首个J2SE的发行版本。2004年9月30日,代号为“Tiger”的J2SE 5.0终于出笼了,这次发布被誉为Java平台历来发布中特性变动最大的一次。包括泛型在内的若干重大语法改进、元数据支持,包括多线程、JDBC在内的多项类库改进,都令广大Java程序员激动不已。自此,Sun的官方JDK(J2SE Development Kit)已经步入了一个新的高度。

 

Eclipse :以架构赢天下
文/恶魔

IBM是在2001年以4000万美元种子基金成立Eclipse联盟,并且捐赠了不少程序代码。如今,该组织有91个会员,包含许多全球最大的软件商。根据Evans Data公司的资料,Eclipse是目前最受欢迎的Java开发工具。
Java厂商若要共同对抗微软,彼此之间就要有共同的开发工具才行。
在Eclipse平台上,程序员可使用好几种不同的语言。在前端方面,用户可整合多种工具来撰写Plug-in程序或Unit Test。Eclipse最大的特色就在于其完全开放的体系结构,这代表任何人都可下载并修改程序代码,给Eclipse写插件,让它做任何你能想到的事情,即所谓“Design for everything but nothing in particular”。
Eclipse基金会的架构比较特别,反映出企业现今对于开放原始码计划也越来越积极主动。Eclipse不像一般开放源码软件容许个人的捐献程序,该基金会是由厂商主导。不论是董事会成员或者是程序赞助者几乎都来自于独立软件开发商(ISVs)的员工。
Eclipse首席执行官Mike Milinkovich说,这种厂商会员制是特意设计的;他说Eclispe软件开发快速就是因为会员制的关系,同时又加上开放源码开发模式的临门一脚。这与一般透过标准组织的做法全然不同。 这其实正好验证了一句老话:“开放即标准”。


JUnit/Ant : 让Java自动化的绝代双骄
文/刘铁锋

在Java程序员必备的工具中,共 同拥有且交口称赞的恐怕就非JUnit、Ant莫属了。一个是单元测试的神兵利器,一个是编译部署的不二之选,它们让Java的开发更简单。
JUnit由XP和TDD的创始人、软件大师Kent Back以及Eclipse架构师之一、设计模式之父Erich Gamma共同打造。名家的手笔和理念使得JUnit简单而强大,它将Java程序员代入了测试驱动开发的时代。JUnit连任了2001、2002年“Java World编辑选择奖”以及2003年“Java World最佳测试工具”和2003年“Java Pro最佳Java测试工具”等众多奖项,深受Java程序员好评。
Ant是开源项目的典范,它让IDE的功能更加强大,从Sun的NetBeans到JBuilder,主流的IDE中处处都有它的身影。“Another Neat Tool”原是它的本名,但这已经渐渐不为人知。它彻底地让部署自动化,而程序员需要做的仅仅是几条简单的配置命令。和JUnit一样,Ant也荣获了众多的殊荣:2003年JavaWorld“最有用的Java社区开发的技术编辑选择奖”, 2003年Java Pro“最有价值的Java部署技术读者选择奖”,2003年“JDJ编辑选择奖”,也让Ant受到的多方的认可。
Ant对JUnit的全面集成,则使得一切都变得更加完美。只需简单地配置,从自动测试到报告生成,从编译到打包部署均可自动完成。强大的功能,简单的配置,让Java程序员高枕无忧。实可谓让Java自动化的绝代双骄。

Websphere : 活吞市场的大鲸
文/jini

1999年, IBM与Novell签订合作协议,成功地提供电子商务的解决方案给予原先使用NetWare的用户。同年更是推出了WebSphere Application Server 3.0,并且推出WebSphere Studio与VisualAge for Java让工程师可以快速开发相关的程序。2001年,IBM更是宣布将应用服务器、开发工具整合在一起,与DB2、 Tivoli及Lotus结合成为一套共通解决方案,如今、IBM更是并入了Rational Rose ( UML tools )让开发流程更是完整化。
Sun在Web Services的策略方面远远落后于微软与IBM, 当他们手拉手在研订Web Services规范, 加上IBM买硬件送软件或是买WebSphere送DB2的策略让企业大佬们纷纷转向IBM的阵营, Sun才惊觉大势已去。WebSphere复杂的安装,深奥的设定,难以理解的出错讯息不断地挑战开发者的耐心与毅力。
IBM如今已经不是将WebSphere定义为单一产品,它已经是一个平台的代名词。它里面的产品目前包含了应用服务器、商业整合、电子商务、 数据讯息管理、网络串流、软件开发流程、系统管理、无线语音等等。非常多样化,也让企业界愿意相信WebSphere可以带给他们一套完整的解决方案。同时, IBM也在推广SOA的概念, 简单来说, 利用Web Service的耦合性与工作流程的整合, 为企业内部打造以服务为导向的架构。
IBM捐献出Eclipse带给Java开发人员对IDE的重新掌握。未来是否会捐献出WebSphere的哪一个部分成为OpenSources, 或许, 又是改写Java世界的时刻了。

 

WebLogic : 技术人的最爱
文/jini

1995年, BEA成立了, 初期以Tuxedo数据转换的产品为基础, 成长之迅速是历年来最强的企业。 1998年, BEA推出以Java为基础的网络解决方案, 提供了完整的中间层架构, 更同时支持EJB 1.0 及微软的COM组件, 方便的管理接口掳掠了工程师的心。 在IBM和Oracle尚未准备好迎击的时候, BEA已经席卷企业应用平台的市场。 WebLogic无论在市场领先度与技术领导性与策略远观性都优于当年的所有应用服务器厂商。
如今WebLogic不仅仅是应用平台服务器的名称, 而是BEA对于整个企业解决方案的总称, 无论是WebLogic Portal或是WebLogic Integration配合着Workshop开发环境, 来自微软的UI开发团队让Workshop几乎达到所见即所得。 接着, 在下一个版本之中, BEA的BeeHive开放源代码计划将释出中间层控件的开发模块, 并且与Eclipse合作共同打造新一代的开发环境。 如此强而有力的技术支持, 更是让顾客愿意使用WebLogic平台的最大原因。
代号为“Diablo”的 WebLogic Server 9.0小恶魔已经出现了, 目前虽然仅仅是BETA版, 以Portlet 方式打造的管理接口与完整且美妙的WebServices支持, 实在很难找到可以挑剔的地方, 虽然去年被IBM的技术性推销超越了市场占有率, 不过接下来SOA的平台竞争现在才开始, BEA的LOGO也加入“Think liquid”并且推出新的AquaLogic平台做为数据服务平台, 可见, Java的应用服务器的战争, 还会继续进行着。

 

JBuilder : Java开发工具的王者
文/刘铁锋

Java的开发工具中,最出名的莫过于Borland公司的JBuilder了。对于一些没有弄清楚开发工具与JDK的区别的Java入门者来说,JBuilder就如同Visual C++之于C++,以为JBuilder就是Java的全部。比起捆绑在服务器上销售的JDeveloper,JBuilder应该是唯一的仅靠自身的实力而占领了大部分市场的Java商用开发工具了。而JBuilder作为Java 开发工具的王者,其夺冠之路并非一帆风顺。直到Java的天才Blake Stone成为JBuilder的Architect之后,JBuilder 2.0以及3.0才逐渐推出。2000年3月14日,JBuilder 3.5的推出别具意义,它成为了业界第一个用纯Java打造的开发工具,也风靡了整个Java开发工具市场。在同年11月份推出的JBuilder 4.0乘胜追击,冲破了50%的市场占有率,成为了真正Java开发工具的王者。
Borland以每半年左右推出一个新版本的速度,让众多的对手倒在了沙场。而Microsoft因为与Sun的官司,也使得一个强大的对手退出了战争。2001年,加入了对企业协作支持的JBuilder 5以及强化了团队开发工具的JBuilder 6打败了最后一个对手Visual Age For Java。2002年JBuilder 7推出之后,再也没有其他厂商与JBuilder竞争。
孤独的王者并没有停下脚步,在2003年到2005年间,JBuilder也仍然延续了其半年一个版本的速度,推出了8、9、10、2005四个版本。强大的功能以及持续的改进,也让Java程序员多了一分对能够在开发工具市场上与Microsoft血拼十数年的Borland的敬仰。

 

Oracle : Java人永远的情结
文/熊节

在林林总总的数据库之中,有一种尤其令人又爱又恨、印象深刻,那就是关系型数据库市场的“大佬”——Oracle。
从公司的角度,Oracle和Sun有着诸多相似之处,例如:两家公司都拥有一位个性鲜明的CEO。早在Java诞生之初的1995年,Oracle就紧随NetScape从而第二个获得了Java许可证。从那以后,Oracle对Java的鼎力支持是Java能够在企业应用领域大获成功的重要原因之一。
所有J2EE程序员都知道,Oracle的JDBC驱动虽然与Oracle数据库配合良好,但在不少地方使用了专有特性。其中最为著名的就是“CLOB/BLOB问题”,诸如此类的问题给开发者带来了很多麻烦。为了同时兼顾不同的数据库,他们不得不经常把自己的一个DAO(数据访问对象)写成两份版本:针对Oracle的版本和针对其他数据库的版本。有不少人为了开发便利,舍弃了数据库之间的可移植性,将自己的产品绑定在Oracle的专有特性上。
Oracle提供的Java开发工具也与此大同小异。不管是数据库内置的Java支持还是JDeveloper IDE, Oracle的Java工具都和Oracle数据库有着千丝万缕的联系。看起来,只要Oracle还是数据库市场上的“头牌”,了解、学习Oracle的专有特性,周旋于Oracle特有的问题和解决方案之中,就将仍旧是J2EE程序员在数据库基础和SQL之外的必修功课。对Oracle的爱与恨,也将仍旧是Java人心头一个难解的情结。

 

Struts、Hibernate : 让官方框架相形失色的产品
文/刘铁锋

好的框架能够让项目的开发和维护更加便捷和顺利。相比Sun官方标准的迟钝以及固执,开源框架也更得到Java程序员的共鸣。Struts以及Hibernate就是这样一类产品,它们简单、优雅,更让官方的产品相形失色。
谈起Struts,不可避免地就要提及MVC(Model-View-Controller)的理念。而准确地讲,MVC的提出却最早源于JSP的标准。在1998年10月7号,Sun发布的JSP的0.92的规范中提出的Model 2就是MVC的原型。在1999年12月Java World的大会中,Gavind Seshadri的文章最早阐述了Model 2就是一种MVC的架构,同时也提及了MVC架构是一种最好的开发方法。2000年3月,由Craig McClanahan发布的Struts成为了最早支持MVC的框架。Struts在设计上虽然存在一些诟病,但是不可否认的是,它使得Java Web应用的开发更加简洁和清晰,也让更多的程序员爱上了Java,并开始遗忘官方的JSP。时至今日,比起如WebWork、Tapestry以及Sun官方的JSF,Struts或多或少存在些不足,但是众多成功项目的实施,仍然使其牢牢占据的Java Web应用框架的首位。
Hibernate则在某种程度上改变了人们对构建J2EE的思路。相比其EJB的Entity Bean的映射技术,Hibernate则显得更加简洁和强大。五分钟就能把Hibernate跑起来,让更多的Java程序员享受到了开发的乐趣。第15届Jolt大奖中,最优秀数据库、框架以及组件的奖项中,Hibernate当仁不让获得头筹;不仅如此, Hibernate甚至还影响了官方的标准。在众多Java程序员翘首以待的EJB 3.0的规范中,Hibernate得到了支持。
Java开源的繁荣不仅让众多Java的开发者享受到了更多的便利,甚至影响了官方的标准。恐怕这也是作为Java人独有的乐趣之一吧。

PetStore : J2EE人的必修课
文/陶文

很少有一个例子项目如PetStore这 般广为人知,而这很大程度上要归功于Sun很“英明”地把PetStore做成一个只展示架构而在性能调优上留下了大大余地的例子。围绕着性能话题,产生了颇为有趣的厂商之间以及平台之间的Pet Wars。除去这些关于性能的流言蜚语乃至中伤,PetStore在展示J2EE1.3平台的架构、演示什么叫分层方面还是有着很大的功劳的。而且PetStore在架构方面的丰富性使得其成为J2EE的那些轻量级小兄弟们展示自身的一个必选科目。
不谈那些围绕PetStore的口水,那些数不尽的盗版,PetStore给开发新手带来的最重大的影响,我想应该是架构的观念而不是性能,也不是业务。做为一种技术的Demo,这无可非议。但是如果你是一个新手,跟着PetStore亦步亦趋地学习J2EE开发,难免会陷入过度设计、华而不实之类的困境。围绕着.NET的PetStore的克隆PetShop展开的架构与性能的大讨论,是不是也在促使我们学习新技术时应该以解决问题为导向呢?特别是当你想把一个如PetStore这般的Sample Project的技术照搬到你的现实世界的Real Project来时。

十大组织

Sun : 因为Java而永被荣光
文/孟岩

Sun是1980年代初期由斯坦福大学三位年轻学生创立的公司。与一般人的印象不同,“SUN”的本意并不是企图剽窃天上那颗温暖的恒星的威名,而是“斯坦福大学网络”的意思。Sun在“前Java”时代就因为SPARC芯片、Solaris操作系统和“网络就是计算机”的口号而为人所知。1990年12月,Sun启动了一个看上去没什么意思的嵌入式软件项目。然而,基于C++的开发很快遇到了麻烦。一个创新型技术公司的特色立刻显示出来,一群天才不是去深入C++,而是另辟蹊径,发明了Java。这个传奇故事已经尽人皆知,但是其中所包含的精神却始终令人望空凝思。
Java的发明,使得Sun真正有机会在软件的历史天空中放射出太阳的光芒。Sun发明了Java,并且在长达十年的时间里始终走在Java大潮的最前端。Sun是Java的老家,是Java慈爱的母亲,这一切任何人都改变不了。虽然Sun似乎没能够从Java中获得应有的金钱回报,但这丝毫没有挫伤Sun对于Java的母爱,还有对于Java大潮的舍我其谁的领导气概。
所有人都迷恋富有的感觉,但是也迟早会意识到钱不是世上最宝贵的东西。这个世界并不缺少会赚钱的公司,但是能够靠着创新型技术推动整个世界进步的公司却是凤毛麟角。Sun应该感到骄傲,他们将因为Java而在历史的天空里发射出太阳的光芒。

 

IBM : Java经济的最大受益人
文/恶魔

Sun公司是Java的发明人,但IBM却是Java最大的受益者。是IBM抢占了利润丰厚的应用服务器市场的头把交椅,是IBM在Java技术上投入最多的金钱,拥有最大的影响力和最好的开发者社区。可以毫不夸张地说,Java使IBM的软件体系得到复兴,在某种意义上,甚至可以说,是Java创造了这种复兴。Java之后又来了Linux,这种建造在不属于自己的平台上以获得成功的理念更是变得非常有影响力。正是这种理念铸就了今天IBM “按需计算,服务为王”的王者风范。
2004年三月,IBM以Java的解放者的姿态借机向Sun发难。IBM公司负责新兴技术的副总裁史密斯在一封公开信中表示,IBM愿意与Sun合作成立一个项目,意在通过开放源代码开发模式管理Java的开发工作。
墙内开花,墙外香。面对IBM的成功,到底是谁妒嫉呢?或许去程序的社区中逛逛聊聊,明眼人是不难发现事实真相的。也许Sun应该好好向IBM学习经营之道。尽管利润额不如硬件及服务部门,但IBM软件部门的利润率是最高的——高达85%的利润率足以令人惊叹。在最近的一个季度里,IBM软件部的利润率上升了8%,其中WebSphere产品组的利润率上升了14%。
正是IBM在开源和Java上的全身心地投入又秉承开放性的原则,今日的Java才能以日进千里的速度将许多竞争对手远远抛在后面。Java 10年,IBM功不可没。

 

BEA : 用AppServer影响Java阵营
文/霍泰稳

十年前诞生的Java并不是一开始 就那么引人注目的,虽然用Applet也曾为互联网络带来一抹亮色,但毕竟只是Toy。在企业级应用市场上,Java一直没有什么起色,虽然Java的支持者一直在鼓吹它有着大型企业级应用的强悍功能。过高的期望与低能的产品,一时间颇让人怀疑Java的路是否已经走到了尽头?可以说是WebLogic Server的出现逐渐打消了人们的顾虑,BEA公司慧眼独具在2001年收购的这个产品将人们的目光吸引到电信、金融、政府等Java企业级应用方面,WebLogic Server以其优良的性能让人们看到Java应用广阔的未来。虽然随后在Java应用服务器方面出现了像IBM公司的WebSpere、开源软件JBoss等Java应用服务器,但WebLogic Server几乎占领世界前500强所有企业的应用服务器市场地位依然无法撼动。
Java现在已经不单纯是一个语言,从另一方面它也代表着开放与创新。很多以Java产品为基础的公司或者从事Java开发的程序员骨子里都有着开放与创新的烙印,BEA公司的发展深深地印证了这一点。与合作伙伴的密切合作向Java社区贡献产品基础源代码、加入权威开源组织参与Java标准的制定等证实着BEA的开放,而其产品从WebLogic Server一种拓展到WebLogic Platform、WebLogic Portal、WebLogic Workshop等其它领域又证实着它的创新能力。

 

Oracle : 早起的鸟儿有虫吃
文/孟岩
Oracle的老板拉里?艾利森是有名的混世魔王和花花公子,所以尽管他也是软件产业成功人士的代表,却绝不是程序员们心目中的英雄,程序员们毕竟不是央视《对话》节目里群众演员,没必要为了节目需要而对权贵财阀们做出一副贱骨头状。但是,任何人都不能不钦佩Oracle在技术上的前瞻性和坚决性。Oracle是1996年获得Java许可证的,紧接着就大胆地将Java作为战略性的发展方向而予以全面支持。要知道当时Java的前景并不是十分确定的,而Oracle的坚决投入,使得它在后来的Java世界中抢得一席之地。1998年9月发布的Oracle 8i为数据库用户提供了全方位的Java支持。Oracle 8i成为第一个完全整合了本地Java运行时环境的数据库,开发者用Java就可以编写Oracle的存储过程,这意味着可以仅在Oracle数据库中就完成几乎全部的应用开发。J2EE兴起后,Oracle更是有心进入开发工具市场,因而购买了JBuilder的源码,并在此基础上开发出JDeveloper。如今Oracle除了数据库稳居第一之外,在Java开发工具世界里也自成一派。这一切不能不归功于当初的眼光远大。


Apache : 开源软件的品牌保证
文/陶文

Java程序员的日常工具箱中,我们可以发现Ant、Tomcat、Log4、Lucene这些鼎鼎大名的开源产品。而它们的共同点在于,都是由Apache Software Foundation社群中杰出的开发者开发的开源项目。Apache这个名字在Java的世界中实在太出名了,以至于“Apache”这六个字母成为开源项目品质保证的代名词。Apache是自由开源的一面旗帜,其Apache License更是成为商业友好的License的首选,只SourceForge上就有1000多个以Apache License授权的项目,其流行程度可见一斑。
但是,如我们所知,Apache最早闻名IT界是靠高性能的Web服务器,其历史甚至和Java一样长。Apache对于Java的偏爱,以及其发展的速度也映射出了Java繁荣的一角。现在去它的主页上看看,满目望去全部都是Java的开源项目,早就不光是其C服务器的老本行了。Apache对Java最大的贡献就是提供了这么一个精品的开放舞台,让杰出的开发者和成熟的开源项目走到一起,共同给Java语言提供一个丰富的工具仓库。对于一种语言、一个平台来说,其库的丰富程度对于开发者来说的重要性再怎么强调也不为过。勿庸置疑,Aapache上会出现越来越多的Java开源项目,而我们开发者也将更多地得益于这令人目不暇接的繁荣。

 

TheServerSide : 论坛的专业精神
文/刘天北

成立于2000年5月,TSS最初以一本书而广为人知。它的创始人Ed Roman同时也是J2EE名著《Mastering EJB》的作者;Roman运营着一个J2EE咨询/培训公司TheMiddlewareCompany(简称TMC),TSS当时是TMC的下属部门;为了扩大企业的影响,Roman在TSS网站上免费发布了那本书的电子版。J2EE程序员要吃下这个香饵,就得在论坛中注册;注册的同时,多半也会看一眼论坛的内容;一看之下,大部分人都被吸引住,成了社区的忠实成员。
TSS究竟有什么吸引人的秘诀?首先,它有一支能力过人的运营团队,除了Roman本人之外,其中还有好几人都是J2EE领域的顶尖专家;第二,TSS和TMC定期会推出专家研讨会/视频访谈、技术白皮书、评测报告,通读TSS提供的这些内容,基本上就可以把握技术的当前趋势。但这还不是全部。最可贵的还是TSS的社区风格:他们深谙技术,但不盛气凌人;思想敏锐,但不因此缺乏审慎和大局感。其中大多数人都已在自己的开发领域颇有建树,在TSS上的活动既给他们提供了与同行进行深度交流的机会。一个新成员进入社区,就像参加了一个起点很高的专业俱乐部,这不是一个求解“怎样设置JAVA_HOME环境变量”之类问题的地方。事实上,在J2EE技术发展的若干转折点上,TSS都起到了关键的推动作用。
几经易主之后,J2EE咨询培训公司TMC在2004年关闭;TSS则被IT媒体集团TechTarget收购。我们期待着它更加繁荣的未来。

JBoss : 职业开源软件组织
文/刘天北

J2EE的婴儿期,“应用服务器”原本是“昂贵”的代名词。但从1999年起,Marc Fleury和Rickard Oberg等人就已经着手改变这种状况。他们开发的开源EJB容器当时叫做“EJBoss”,在Sun公司的干预下(注意,“EJB”是注册商标),JBoss获得了今天的名字。虽然从问世起就一直受到关注,但JBoss第一个达到产品化标准的版本可能是它的2.2版。它的易用让人一见难忘:除了标准部署描述符,无需编写专用的xml配置文件。Oberg自豪地说,“我们的架构并不是按照EJB规范指定的路线设计的,因此也没有走大多数应用服务器走过的弯路。”
Jboss 3.x版本保持了一贯的创新精神,在用户中间获得了更广泛的认可。但是,文档要收费下载、在邮件列表上提问常常会遭到Fleury等人的斥责。无疑,JBoss的创始者也意识到了自己的幼稚:开源软件只能靠服务盈利,卖文档赚钱有限、骂用户当然更损害企业形象。
虽然以Oberg为首的许多程序员退出了开发队伍(其中很多人成了JBoss的死敌),在开源软件领域也面临JOnAS Geronimo等新老对手的竞争,但JBoss还是以不断推出的新版本站稳了脚跟。在技术上,它是策动J2EE演进的重要力量:拟议中的EJB 3也要追随Jboss 4倡导的开发范式,以至于二者的代码样本之间的差别几乎难以分辨;在商业上,JBoss与Sun公司言和修好,甚至还获得了数量可观的风险投资。JBoss已经像拥护者预期的那样,成为了应用服务器领域的Linux。

 

Borland : 深度介入Java
文/左轻候

除了Sun以外,也许没有一家公司 像Borland这样深层地介入Java。Borland开发了最早的Java编译器之一,Borland的工程师参与了早期JDK的设计,Borland的JBCL(JavaBeans Component Library) 技术也成为后来Java Bean规范的基础。但是Borland对Java世界最大的影响还是JBuilder。
1997年11月,Borland JBuilder 1.0发布。虽然第一个版本相对于竞争对手并没有表现出明显的优势,但是Borland凭借深厚的技术实力和正确的市场策略,不断地超越了对手。JBuilder 3.5成为业界第一个100%基于Java架构的开发工具,并且市场份额很快超过了50%。在随后的版本中,JBuilder持续改进对团队开发、J2EE架构、Mobile技术等方面的支持,最终成为了Java开发工具市场,特别是大型企业级Java开发市场中的霸主。JBuilder的成功,很大一个原因来自于Borland坚持的平台中立性,即对不同厂商的解决方案提供一视同仁的支持。
2005年初,随着Eclipse社区的迅速崛起,Borland进入了Eclipse的董事会,成为战略开发者(Strategy Developer) ,并宣布将推动Borland的其它产品与Eclipse的集成。在随后发布的一份文件中,Borland宣称JBuilder的未来版本将放弃原有的PrimeTime架构,而基于Eclipse架构。这个代号为“Peloton”的版本预计于2006年下半年发布。
Borland对Java的另外两个主要贡献来自Together和BES(Borland Enterprise Server)。Together是著名的建模工具,能够与包括JBuilder在内的许多开发工具进行集成,全球市场份额占有率排名第二。BES AppServer是一种J2EE服务器,在全球市场份额占有率上次于WebLogic和WebSphere,排名第三。

 

JCP : Java世界的联合国
文/黄海波

当联合国正在为安理会改革问题 吵得如火如荼时,Java世界的“联合国安理会”已经成功地运作了七个年头。JCP(Java Community Process)在1998年由Sun发起成立,目标是通过一个开放、合作和鼓励参与的非盈利组织来发展和推进Java和相关的技术。正是由于JCP计划的推出可以让所有对Java感兴趣的软硬件厂商,个人和组织都能参与到技术规范的制定和发展过程中,协调各方的兴趣和利益、集思广益,才可以让Java在短短的几年内异军突起,成为可以和微软开发平台抗衡的一个主流开发语言。JCP计划既然是一个组织,自然也有一定的架构。JCP组织架构主要包括PMO(Program Management Office)、JCP成员、EC、EG。事实上,JCP的架构就好像一个Java世界的联合国。虽然也有不少人批评JCP成为各派利益的角力场,因而效率低下;但是,它毕竟为Java的顺利发展很好地掌握了方向。

 

微软与Java : 不得不说的故事
文/孟岩


微软跟Java不对付,地球人都知 道。跟Sun和解了又怎么样?  .NET跟Java就是竞争对手,没什么说的。但是有点IT掌故的人都知道,微软并非一开始就跟Java过不去。当年比尔?盖茨盛赞Java是“长期以来最好的程序设计语言”,而且很早就购买了Java许可证。但是微软作为村里的老大,看着人家的儿子茁壮呈长,不由得生了私心杂念,搞起了小动作,在Visual J++中加入了一些破坏纯洁性的东西。单独来看,Visual J++是COM时代微软最棒的开发工具,用WFC写Windows应用程序和COM组件实在是一种享受。但是放在Java大家庭里,这个家伙就显得多少有点不怀好意。一场官司下来,微软被逐出Java大家庭,Visual J++无疾而终。以后的事情尽人皆知,.NET出笼,利齿直指Java,几年撕咬下来,没占着便宜也没吃大亏,如今也算是南北朝对峙,二分天下有其一。设想如果当时微软能够摒弃帝国主义心态,正确对待Java,与其他人一起共建美好的Java“共产主义社会”,那么今天我们的软件开发世界应该会美好得多。可惜黄粱一梦,终究是蚂蚁的喜事。2004年,微软与Sun实现了和解,但愿到Java 20周年的时候,我们能更正面地描述微软对Java发挥的作用。

posted @ 2010-07-09 16:18 favorer 阅读(244) | 评论 (0)编辑 收藏

2010年4月9日

java路程-规范-javabeans

最近学习javabeans规范,内容不少。
列几个重要的待学习的类:
java.awt.datatransfer .DataFlavor

posted @ 2010-04-09 21:46 favorer 阅读(113) | 评论 (0)编辑 收藏

java路程-javabeans

最近学习javabeans规范,内容不少。
列几个重要的待学习的类:
java.awt.datatransfer .DataFlavor

2010-04-11
beans持久时的进一步了解。关于序列化的内容等见下:
beans相关文档

http://java.sun.com/beans/related.html
“JavaObjectSerialization”.ThisdescribestheautomaticJavaObjectSerialization
mechanism that is the default mechanism for JavaBeans persistence (see Section 5).

posted @ 2010-04-09 21:45 favorer 阅读(212) | 评论 (0)编辑 收藏

仅列出标题  
<2024年12月>
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

导航

统计

常用链接

留言簿(1)

随笔分类

随笔档案

文章档案

友博

名家

搜索

最新评论

阅读排行榜

评论排行榜