Java

J2SE 1.5 － 代號為 Tiger － 計劃在 2003 年年底發布。我一直都熱衷於儘可能多地收集有關即將推出的新技術的預告資訊，因此我將撰寫一系列的文章，討論可從 V1.5 中獲得的新的和經過重組的特性，本文是第一篇。我特別想談談泛型型別並重點講述在 Tiger 中為了支援它們而進行的更改和調整。在許多方面，Tiger 肯定是迄今為止在 Java 編程方面（包括對源語言文法的重大擴充）所取得的最大進步。Tiger 中計划進行的最顯著的變化是添加泛型型別，正如在 JSR-14

臆想實現重溫回想一下 上次介面的 臆想實現是一個合法的實現，但不滿足介面規範的某些未經檢查的方面。我們考慮一下下面的堆棧介面，以及許多未被其單獨的類型簽名捕獲的不變數：清單 1. 一個堆棧接public interface Stack {　 public Object pop();　 public void push(Object top);　 public boolean isEmpty();}例如，請考慮我們希望任意堆棧實現都遵守的下列規則：如果一個對象 o 被壓進堆棧 s

Java 語言介面是一種強大的工具。它具有多繼承的很多優點，而沒有什麼問題。為客戶希望使用的所有服務指定一個介面，使得在需要時插進這種介面的不同實現成為可能。遺憾的是，規範中可以被表達的部分只有方法說明。對任何實現來說，很可能還有很多其它不變數希望被掌握，但是 Java 語言沒有提供檢查它們的工具。臆想錯誤模式由於這種限制，很可能“實現”了一個介面而實際上沒有滿足預期的語義。由這種 Fictitious

Java 程式設計語言的一個特色是儲存自動管理，它把程式員從很容易出錯的釋放使用後的記憶體的工作中解放出來。儘管如此，許多程式還是得處理資源問題，例如檔案和資料庫連接，這些都必須在使用之後明確地釋放掉。跟手工管理儲存一樣，程式員在手工管理資源時也會犯很多錯誤。其中一個就是本周專欄的主題 ― Split

在多線程代碼中，使用驅動其它線程所負責的動作的單個主線程是常見的。這個主線程發送訊息，通常是通過把它們放到一個隊列中，然後其它線程處理這些訊息。但是如果主線程拋出一個異常，那麼剩餘的線程會繼續運行，等待更多輸入到該隊列，導致程式凍結。在診斷 Java 代碼的這一部分中，專職 Java 開發人員兼兼職捉蟲者 Eric Allen

Java理論與實踐: JDK 5.0中更靈活、更具延展性的鎖定機制Java理論和實踐: 一個有缺陷的微基準的剖析Java理論和實踐: 理解JTS ― 平衡安全性和效能Java理論和實踐: 理解JTS ― 幕後魔術Java理論和實踐: 安全構造技術Java理論與實踐: 平衡測試，第3部分：用方面檢驗設計約束Java理論與實踐:平衡測試，第2部分：編寫和最佳化bug檢測器Java理論與實踐:平衡測試，第1部分：不要僅編寫測試，還要編寫buJava理論與實踐:

類路徑可以串連 Java 運行庫和檔案系統。它定義編譯器和解譯器應該在何處尋找要載入的 .class 檔案。它的基本思想是：檔案系統的階層反映了 Java 包的階層，而類路徑則定義了檔案系統中的哪個目錄可以作為 Java 包階層的根。遺憾的是，通常檔案系統非常複雜並依賴於平台，而且和 Java 包也不能很好地匹配。尤其是在 Windows 環境中更是如此。Java 是一些 Unix 高手設計的，因而從很多方面來說，這也就意味著它無法很好地與 Windows

譯者注 :你可能會覺得Java很簡單，Object的equals實現也會非常簡單，但是事實並不是你想象的這樣，耐心的讀完本文，你會發現你對Java瞭解的是如此的少。如果這篇文章是一份Java程式員的入職筆試，那麼不知道有多少人會掉落到這樣的陷阱中。摘要本文描述重載equals方法的技術，這種技術即使是具現類的子類增加了欄位也能保證equal語義的正確性。在《Effective Java》的第8項中，Josh

引言java的堆是一個運行時資料區,類的執行個體(對象)從中分配空間。java虛擬機器(jvm)的堆中儲存著正在啟動並執行應用程式所建立的所有對象，這些對象通過new、newarray、anewarray和multianewarray等指令建立，但是它們不需要程式碼來顯式地釋放。一般來說，堆的是由記憶體回收來負責的，儘管jvm規範並不要求特殊的記憶體回收技術，甚至根本就不需要記憶體回收，但是由於記憶體的有限性，jvm在實現的時候都有一個由記憶體回收所管理的堆。記憶體回收是一種動態儲存裝置管理技術

代碼審查是消滅Bug最重要的方法之一，這些審查在大多數時候都特別奏效。由於代碼審查本身所針對的對象，就是俯瞰整個代碼在測試過程中的問題和Bug。並且，代碼審查對消除一些特別細節的錯誤大有裨益，尤其是那些能夠容易在閱讀代碼的時候發現的錯誤，這些錯誤往往不容易通過機器上的測試識別出來。本文就常見的Java代碼中容易出現的問題提出一些建設性建議，以便您在審查代碼的過程中注意到這些常見的細節性錯誤。通常給別人的工作挑錯要比找自己的錯容易些。別樣視角的存在也解釋了為什麼作者需要編輯，而運動員需要教練的原因

在他的關於 JTS 的系列文章的第 1 和第 2 部分，Brian 講述了一些基礎知識，包括什麼是事務以及 J2EE 容器如何使事務服務對 EJB 組件透明。儘管能夠以聲明的方式而不是編程的方式指定組件的事務性語義可以大大增強配置公司專屬應用程式程式時的靈活性，但在裝配應用程式時做出不當的決定會削弱應用程式的效能和穩定性。在這最後一部分，Brian 討論了 J2EE 提供的用來管理事務劃分和隔離的工具和一些高效率地使用這些工具的指導。請單擊文章頂部或底部的 討論，在

在這個關於事務的系列文章的 第 1 部分，我們講述了一些基礎知識，包括什麼是事務，以及事務對於構建可靠的分布式應用程式來說至關重要的原因。在這一部分，我們將探討如何將 J2EE 應用程式構建到事務中，以及 JTS 和 J2EE 容器如何設法使事務服務（包括事務劃分、資源徵用和事務傳播）對組件程式員來說幾乎是不可見的。請單擊文章頂部或底部的 討論，在 討論論壇與作者和其他讀者分享您對本文的想法。在這個系列的 第 1 部分，我們討論了事務並研究了它們的基本屬性 ―

Java工具 + 生產力類庫中的類java.util.Random提供了產生各種類型隨機數的方法。它可以產生int、long、float、double以及Goussian等類型的隨機數。這也是它與java.lang.Math中的方法Random()最大的不同之處，後者只產生double型的隨機數。類Random中的方法十分簡單，它只有兩個構造方法和六個普通方法。構造方法：(1)public Random()(2)public Random(long

引言在過去數年裡，隨著全球資訊網聯盟（World Wide Web Consortium，W3C）更新了核心規範，並引入了彌補 Web服務最初缺陷的新規範，Web服務發生了大量的變化。W3C 的Web Services Activity 小組所維護的規範以獨立於供應商的方式將 Web服務作為一組 XML 規範進行處理。同時，Java™ Community Process (JCP) 也在維護自己的規範集，以將 W3C 的建議合并到 Java 語言中。Java APIs for

Web 服務的力量在於互通性。由於業界在 Web 服務技術方面（SOAP、WSDL、UDDI）的協作，更具體地說，是由於 Web 服務互通性組織（Web Services Interoperability organization，WS-I.org）的工作，Web 服務才可以與其他的 Web 服務進行互動，而不管 Web 服務開發和運行在哪一個平台上（比如是 Microsoft .NET 還是 IBM WebSphere）。Web 服務客戶機分為多種類型，比如另一個 Web

Liar, liar!設想一下：您已經為一個分布式系統精心設計了一個極好的 GUI 程式，它包含了客戶機請求的所有東西及其它一些東西。您已經讓它運行通過了一個自動化測試套件的測試 ― 由於不變數的數量是個天文數字，因此，自動化測試是必須的。測試的結果是程式獲得了一張“無錯誤的健康證明書”。發布這個 GUI 的期限到了，但是，作為一個象您這樣嚴格的程式員，只是為了發現錯誤的行為 ―

支援靜態分析（包括類型檢查）的主要論據是：其結果適用程式所有可能的運行，而通過單元測試只能保證被測試的組件（在測試它們的平台上）只適用測試組件的特定輸入。支援單元測試的主要論據是它更容易處理。您可以測試程式的許多約束，這些約束遠遠超出了同期的靜態分析工具所能達到的範圍。請允許我在此冒昧地說一句：我認為將這兩種工具看作對立的是一個錯誤。每種工具都有助於構建更健壯的程式。實際上，它們可以通過非常強大的方式進行互補。每種工具都有各自的長處，對於補充另一種工具特別有用：單元測試能顯示執行的常用路徑，從而

儘管傳統的斷言可以增加對 Java 代碼所作的檢查次數，但僅用它們，還是有許多檢查無法完成。處理這種情況的方法之一就是使用 時態邏輯。請回憶上個月的文章“ Assertions and temporal logic in Java

在 Java 語言中獲得單繼承編程的安全性需要付出極大的代價：有時必須沿著繼承階層中的多條路徑複製代碼。要重新獲得單繼承 Java 代碼中所失去的大多數表示，我們可以將 mixin整合為一個擴充。本月，Eric Allen 解釋了 mixin（那些由它們的父類參數化類別）的概念，以及它們如何能協助單元測試。他還描述了基於 mixin 編程的工具，並討論了將 mixin 添加到您的 Java 代碼中的可能方法。自從物件導向的編程出現以來，OO

要構建可靠的軟體，程式規範很關鍵。沒有良好定義的規範，很難診斷軟體系統的異常行為。但是很多軟體系統的程式規範定義得很差勁。而且更糟的，是許多軟體系統根本就沒有規範。直觀的看，程式規範是對程式行為的一種描述。它可以採取許多形式，但無論採取何種形式，都有一條主線貫穿所有執行個體：必須有某種類型的系統規範，因為您得依靠它來判斷系統是否運轉正常。規範可以形式化也可以鬆散地定義，這取決於開發中系統的穩定性和危險程度，還與開發完畢後修改系統的容易程度有關。我們將通過討論規範為什麼重要、為什麼會經常被忽略以及