其他

在J2EE應用中，我們經常通過JDBC訪問企業資源。但JDBC用的不好，將會影響系統的效能。本文參照John Goodson的《Performance Tips for the Data Tier(JDBC)》一文，寫成此文，希望對我們的開發有所協助。本文從以下四個部分加以說明：l    適當地使用資料庫的中繼資料方法l    檢索需要的資料l    選擇最佳化效能的功能l    管理串連和資料更新1.    適當地使用資料庫的中繼資料方法1.1.    盡量少用中繼資料方法由於中繼資料方法執行

原文：http://today.java.net/pub/a/today/2003/10/24/swing.html?page=1不正確的Swing線程是運行緩慢、無響應和不穩定的Swing應用的主要原因之一。這是許多原因造成的，從開發人員對Swing單執行緒模式的誤解，到保證正確的線程執行的困難。即使對Swing線程進行了很多努力，應用線程邏輯也是很難理解和維護的。本文闡述了如何在開發Swing應用中使用事件驅動編程，以大大簡化開發、維護，並提供高靈活性。背景既然我們是要簡化Swing應用的線

本文討論區對話和Swing組件。目的不僅是為了協助你以安全執行緒的方式使用Swing API，而且解釋了我們為什麼會選擇現在這樣的線程方案。本文包括以下內容：單線程規則：Swing線程在同一時刻僅能被一個線程所訪問。一般來說，這個線程是事件派發線程（event-dispatching thread）。規則的例外：有些操作保證是安全執行緒的。

現在網上有很多推薦利用ServletFilter和ThreadLocal來處理資料庫連接池或者是Hibernate的Session工廠，原理就是結合ThreadLocal使整個請求過程用的是同一個串連執行個體或者Session執行個體！好處是1. 不用多次從串連池取串連，效能較佳（這點我持懷疑態度，因為從串連池中取串連的消耗可以忽略不計）2. 可以利用Hibernate的lazy load的特性3. 代碼更加簡介、好看4. 資源可以被可靠的釋放但是我要給用這種方法的人提個醒，先列兩個缺點：1.

本文給出了一些使用SwingWorker類的例子。SwingWorker類的目的是實現一個後台線程，讓你可以用它來執行一些費時的操作，而不影響你的程式的GUI的效能。關於SwingWorker類的一些基本資料，請參閱《線程和Swing》。對執行一些費時或可阻塞操作的Swing程式來說，線程是基本的解決之道。例如，如果你的應用程式要根據使用者選擇的功能表項目發出一個資料庫請求或載入一個檔案，那麼你應該在一個單獨的線程中完成這些工作。本文闡述了在一個分離的worker線程中完成上述工作的途徑。本文包

JBUILDER的版本飛的太快了,一個版本還沒有搞明白和前一個版本的不同之處,下一個版本又出來了!每個版本肯定都有改進,但如果不使用比較深入的功能,也覺得版本的改進不是太大(我就是這樣^_^,每升級一次就覺得漂亮多了).我在用7開發EJB的時候遇到的BUG到9才改掉,這也是我多次升級帶來的唯一一次好處.不過這次JBUILDER X給我感覺倒的確是一次裡程碑式的升級,剛剛download下來了,簡單的試用了一下,下面是俺的初體驗:

每一次看這部片子的時候，都會覺得特別有意思，就像劇中所說：酒越喝越暖，水卻越喝越寒。但是改一下，不知道會是什麼樣的樂趣。哈哈！歐陽峰（獨白）：很多年之後,我有個綽號叫做西毒,任何人都可以使用盜版，只要你見過Microsoft如何如何賺錢,我不會介意他人怎樣看我,我只不過不想讓Microsoft賺得更多。歐陽峰（獨白）：看來你用電腦的年月也有幾年了吧，這幾年中，你總會有一些喜歡的應用程式，或是想玩的遊戲，有些可以讓你減少很多工作，有些則可以讓你好好的過把癮，可是你沒有。呵，只要看一下報價，你就會說

介紹與回顧在鑽研樹、表和非同步模型之前，我首先回顧一下Swing的單線程規則（single-thread rule）並檢驗它的含義。Swing的單線程規則是說，Swing組件在某一時刻僅能被一個線程訪問。這個規則對gets和sets都有效，並且“一個線程”通常指的都是事件派發線程。單線程規則應用於UI組件是非常相稱的，因為UI組件往往都以單線程方式使用，並由使用者發起大多數動作。構建安全執行緒的組件是困難而冗長乏味的：如果能避免則最好不過。但除了它的好處，單線程規則有更多的含義。Swing組件所

Vector 還是ArrayList――哪一個更好，為什嗎？要回答這個問題不能一概而論，有時候使用Vector比較好；有時是ArrayList，有時候這兩個都不是最好的選擇。你別指望能夠獲得一個簡單肯定答案，因為這要看你用它們幹什麼。下面有4個要考慮的因素：l APIl 同步處理l 資料增長性l 使用模式下面針對這4個方面進行一一探討API 在由Ken Arnold等編著的《Java Programming Language》(Addison-Wesley, June 2000)一書中有這樣的描

單選或多選按鈕訊息（首碼:pbm_bm） pbm_bmgetcheck 選項按鈕或多選按鈕是否被選。 pbm_bmgetstate 按鈕是否加亮。 pbm_bmsetcheck 將無線按鈕或確認框的選中狀態改為未選中狀態,反之亦然。 pbm_bmsetstate 加亮或不加亮按鈕。 pbm_bmchange 改變按鈕的風格,例如,改為選項按鈕或組合框。 單選或多選按鈕通知訊息（首碼:pbm_bn） pbm_bnclicked 按鈕控制項被點中。 pbm_bndisable 使按鈕控制項無效。

豐田生產方式中所歸納的“七種浪費”，主要發生在生產現場，但是產生這些浪費的深層次的原因是什嗎？如果僅僅關注現場存在的浪費，而不解決被現象所掩蓋的本質問題，無疑是捨本逐末。為了使消除浪費的活動深入有效地開展下去，我們首次提出管理工作中的“七種浪費”的概念，來引導大家共同參與這項工作。 一 管理工作不能“等” 在管理工作中，等待的浪費主要表現在以下幾方面： 1. 等待上級的指示

Log4j簡明手冊1. 概述本文主要描述Log4j的API的唯一特性和它的設計原理。Log4j是一個基於許多作者的開放源碼的項目。它允許開發員以任意的間隔來控制日誌的輸出。它通過設在外部的設定檔而達到運行時靈活的設定。最重要的是，Log4j有一個平穩的學習曲線。注意：根據來自使用者的反饋判斷，它很容易使人上癮。2. 導言幾乎所有的大型應用程式都包括它的自己的日誌和跟蹤API。順應這個規則，E.U. SEMPER 項目決定寫它自己的跟蹤PAI。這是1996年初。在無數次加強，幾次變形和許多工作後，

下面是對Hibernate開發工作的個人想法，正是這些工作使得Hibernate如此迅速的得到廣泛的歡迎。1、飛快的版本發布保持活躍的開發速度，經常進行版本發布，甚至幾天之內就從前一個版本開發到下一個版本。這樣是保證軟體遠離Bug的最好的辦法，也可以讓使用者感到很放心，確信Hibernate的開發十分活躍，另外這樣做也有一大好處，就是可以發現哪些功能是使用者真正需要的。2、迴歸測試我想現在整個Java社區一定都很重視自動迴歸測試。如果軟體的功能和設計有比較大的修改，那麼一個綜合性的test

PowerBuilder取得巨大成就的原因就是有Datawindow對象,DataWindow是具有功能強大和靈活多變的特點，本人用PowerBuilder開發過一段時間後，，總結出一些技巧，以供廣大的PB開發人員借鑒使用。　　一．如何建立一個報表，如下形式 Quantity Running Total 5,000 5,000 2,500 7,500 3,000 10,500 12,000 22,500　　對於Running

設計模式使用率熱門排行榜

4. 配置插入日誌請求到應用程式的代碼中需要大量的預先計劃和最終努力。觀察顯示大約4%的代碼是用來輸出的。因此，大小適度的程式都被嵌入有成千個日誌輸出語句。為了以無需手工的方式管理這些日誌的輸出狀態，給日誌輸出以編號和規範變得勢在必行。 Log4j在程式中有充分的可配置性。然而，用設定檔配置Log4j具有更大的彈性。目前，它的設定檔支援xml和java

摘要有經驗的 Java 開發人員都知道寫好 toString 方法很重要。對可用人類理解的形式查看的對象進行記錄和調試都相當容易；當處理分布式應用程式時尤其是這樣。不幸的是，為許多類實現 toString 方法可能相當耗時 -- 尤其是對於那些具有許多屬性的類。因為 toString 的行為相當規則，所以最好使建立該方法的任務能夠自動完成。本文提供的這個公用程式可以協助您實現這一點，同時也減輕了您在開發時的負擔。參與大項目的開發人員通常要花數個小時編寫有用的 toString

以下僅為個人觀點,希望大家討論和完善,並設計較為好用的類庫編寫健壯程式，首先正確的理解類庫,考慮異常處理和輸入參數校正,其次是跟蹤和改進。概念程式的執行就是系統狀態的變化過程， 任何一個方法的執行，對象和系統會進入下一個狀態。錯誤的發生可歸結為:? 參數錯誤?

7. Nested Diagnostic Contexts在現實世界中的系統經常不得不同時處理多個用戶端請求。在這樣的一個典型的多線程的系統中，不同的線程將處理不同的用戶端。Logging特別能夠適應這種複雜的分布式的應用程式的調試和跟蹤。一個常見的區分每個用戶端所輸出的Logging的方法是為每個用戶端執行個體化一個新的獨立的Logger。這導致Logger的大量產生，管理的成本也超過了logging本身。 唯一標識每個log請求是一個輕量級的技術。Neil Harrison

　　設計表現層時需要考慮的幾個問題　　開發人員在設計表現層時，可以使用不同的模型，這時需要考慮一些相關的設計問題。這些問題和模型關係的緊密程度也各有不同，它們可以影響系統的各個方面，包括有安全、資料完整性、可管理性和擴充性。雖然這些設計問題大部分都可以用模型的形式表示，但我們不打算這樣做，因為這樣更為抽象，我們選擇以非正式的文檔形式表示。我們只是根據不同的模型，將每個需要考慮的問題列出來。　　Session管理　　使用者Session指的是跨越一個客戶和伺服器多個請求間的一個對話。我們將在以下部