Java

4.1關於J2EE開發的比喻打個比方.現在的j2ee開發,就好象對面來了一個人.最外面穿著一件風衣(HTML)風衣裡面穿著西裝(Struts)西裝裡面穿著馬甲(Spring)馬甲裡面穿著襯衫(Hibernate)襯衫的裡面才是真實的人(資料庫)全部衣服都是採用棉布做成的(Java)每件衣服上都可能有其他配件(第3方庫)各件衣服之間需要配套使用(版本相容)如果你想看到這個人到底長啥樣,必須得:先脫一件,再脫一件,再脫一件.最後才能看到最終資料庫裡面的資料是啥樣子.在很久很久以前,這個人是不穿衣服的

從總體上來說，構成目前J2EE

既然Groovy語言是Java語言的擴充，那麼我們在使用Groovy語言的時候，就很難與Java語言真正脫得了干係，那怕我們是在做一個純Groovy語言的項目，如Grails項目。我們可能在Groovy代碼中會用到遺留的Java類和包；也可能是為了效能的原因，我們不得不在Groovy語言中使用到Java類；等等。如果我們要對於Java類使用Groovy語言的MOP，比如我們想給一個Java類的對象在運行期內添加一個方法。那麼我們該怎麼辦呢？比如，我們有如下的一個Java類：//（Java代碼）p

5.8 BigDecimal類雙精確度浮點型變數double可以處理16位有效數。在實際應用中，需要對更大 或者更小的數進行運算和處理。Java在java.math包中提供的API類BigDecimal， 用來對超過16位有效位的數進行精確的運算。表5.7中列出了BigDecimal類的主 要構造器和方法。表5.7 BigDecimal類的主要構造器和方法構 造 器描

使用 ApacheDS 和 Acegi 實現存取控制瞭解了 Acegi 安全系統（Acegi Security System）的 基礎知識 後，我們 將介紹該系統的更加進階的應用。在本文中，Bilal Siddiqui 向您展示了如何 結合使用 Acegi 和一個 LDAP 目錄伺服器，實現靈活的具有高效能的 Java™ 應用程式的安全性。還將瞭解如何編寫存取控制策略並將其儲存在 ApacheDS 中，然後配置 Acegi 使其與目錄伺服器互動，從而實現身分識別驗證和授

何時使用多線程技術，以及何時避免用它，這是我們需要掌握的重要課題。骼它的主要目的是對大量任務進行有序的管理。通過多個任務的混合使用，可以更有效地利用電腦資源，或者對使用者來說顯得更方便。資源均衡的經典問題是在IO等候期間如何利用CPU。至於使用者方面的方便性，最經典的問題就是如何在一個長時間的下載過程中監視並靈敏地反應一個“停止”（stop）按鈕的按下。多線程的主要缺點包括：(1) 等候使用共用資源時造成程式的運行速度變慢。(2) 對線程進行管理要求的額外CPU開銷。(3

對一種特殊的資源——對象中的記憶體——Java提供了內建的機制來防止它們的衝突。由於我們通常將資料元素設為從屬於private（私人）類，然後只通過方法訪問那些記憶體，所以只需將一個特定的方法設為synchronized（同步的），便可有效地防止衝突。在任何時刻，只可有一個線程調用特定對象的一個synchronized方法（儘管那個線程可以調用多個對象的同步方法）。下面列出簡單的synchronized方法：synchronized void f(

一次項目研發中需要日期時間選擇控制項，網上提供的不多，且品質一般，所以只好自己做，參考了網上某位同學的作品Jave日期選擇控制項DateChooser 。目前的代碼將日期時間選擇封裝在一個按鈕組件內，應該很好用，支援Application 、AppletCODE:import java.util.Date;import java.util.Calendar;import java.text.DateFormat;import java.text.SimpleDateFormat;import

一個很基礎的小程式，可以作為一種方法嵌入到其他應用中import java.awt.Graphics;import java.awt.Event;import java.awt.Color;public class mouse extends java.applet.Applet{int num=0;//計數器初始化int px,py;public boolean mouseDown(Event evt,int x,int y)//滑鼠按下事件{px=x;py=y;//滑鼠按下時的座標num++

和樹狀物一樣，表格在Swing相當的龐大和強大。它們最初有意被設計成以Java資料庫連結（JDBC，在15章有介紹）為媒介的“網格”資料庫介面，並且因此它們擁有的巨大的靈活性，使我們不再感到複雜。無疑，這是足以成為成熟的電子資料工作表的基礎條件而且可能為整本書提供很好的根據。但是，如果我們理解這個的基礎條件，它同樣可能建立相關的簡單的Jtable。JTable控制資料的顯示方式，但TableModel控制它自己的資料。因此在我們建立JTable前，應先建立一個TableM

列表框和組合框在Swing中工作就像它們在老的AWT中工作一樣，但如果我們需要它，它們同樣被增加功能。另外，它也更加的方便易用。例如，JList中有一個顯示String數組的構建器（奇怪的是同樣的功能在JComboBox中無效！）。下面的例子顯示了它們基本的用法。 //: ListCombo.java// List boxes & Combo boxespackage c13.swing;import java.awt.*;import

JPopupMenu的執行看起來有一些彆扭：我們必須調用enableEvents()方法並選擇滑鼠事件代替利用事件接收器。它可能增加一個滑鼠接收器但MouseEvent從isPopupTrigger()處不會返回真值——它不知道將啟用一個快顯功能表。另外，當我們嘗試接收器方法時，它的行為令人不可思議，這或許是按一下滑鼠活動引起的。在下面的程式例子裡一些事件產生了這種彈出行為： //: Popup.java// Creating popup menus with

DSL 是專門解決特定於域問題的語言。通過更接近問題的操作，DSL 可以提供在通用語言中可能找不 到的好處。Java 世界中充滿了 DSL。屬性檔案、Spring 上下文、標註的某種用法以及 Ant 任務，都是 DSL 的樣本。在開始研究其他像 Ruby 這樣的語言的時候，我開始理解到 Java 語言目前對於 DSL 還沒有良好的把 握。在這篇文章中，將看到 Ruby 使用的四種整合乾淨的 DSL 的技巧。然後，將看到在 Java 語言中可

J2EE系統最佳化的幾點體會（一、對象）說到系統最佳化，是一個比較複雜的問題，涉及到軟體的各個方面：需求、模組劃分、資料庫設計、程式編碼以及一些特殊的最佳化方法如緩衝技術等。而不同的應用又有其特殊的最佳化策略和技術。同時最佳化是貫穿系統從需求到實現再到維護的各個階段的一項活動，而在各個階段又有其不同的著眼點和具體方法。本文立足於具體的J2EE項目實踐，結合一些已有的最佳化條例，提出自己的一些體會，也算是作為一次對實際項目經驗教訓的總結。最佳化一般意義上說是提高已有系統的效能，減少如記憶體、資料庫

1、Oracle8/8i/9i資料庫（thin模式）Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();String url="jdbc:oracle:thin:@localhost:1521:orcl";//orcl為資料庫的SIDString user="test";String password="test";Connection

這裡將模仿Spring實現一種基於xml設定檔的依賴注入機制。檔案中將實現3中注入，一是單值注入 ，包括int,float，double，char等，也包括String注入；二是Java容器注入，包括List，Set，Map三種 容器的注入，最後一種是java bean對象注入。實現的機制是，使用Dom4j對xml設定檔進行解析，這裡使用dom4j的Element Handler機制，一種類 似與責任鏈模式的實現機制；對於java對象的構建使用反射機制，這裡主要是針對得到的類的Field進行

13.4 中文問題網路傳輸過程中的中文問題也比較突出，出現該問題的原因和前面IO部分介紹的一致，都是由於傳輸過程中用戶端程式和伺服器端程式採用的字元集不一致，在解決該問題以前首先進行如下的思考：是否在網路中一定要傳輸中文字元？從前面的樣本中可以看出，通過一定的協議格式設計，可以避免在網路中傳輸中文字元，這樣就從基礎上避免了中文問題的出現。例如在程式中需要傳輸“成功”、“失敗”這樣的中文字串，在協議中可以約定數字0代表“成功”

該樣本的功能是實現將用戶端程式的系統時間發送給伺服器端，伺服器端接收到時間以後，向用戶端反饋字串“OK”。實現該功能的用戶端代碼如下所示：package udp;import java.net.*;import java.util.*;/*** 簡單的UDP用戶端，實現向伺服器端發生系統時間功能*/public class SimpleUDPClient {　public static void main(String[] args) {　　DatagramSocket

Java號稱對Unicode提供天然的支援，這話在很久很久以前就已經是假的了（不過曾經是真的），實際上，到JDK5.0為止，Java才算剛剛跟上Unicode的腳步，開始提供對增補字元的支援。現在的Unicode碼空間為U+0000到U+10FFFF，一共1114112個碼位，其中只有1,112,064 個碼位是合法的（我來替你做算術，有2048個碼位不合法），但並不是說現在的Unicode就有這麼多個字元了，實際上其中很多碼位還是閒置，到Unicode 4.0

如果你是JVM的設計者，讓你來決定JVM中所有字元的表示形式，你會不會允許使用各種編碼方式的字元並存？我想你的答案是不會，如果在記憶體中的Java字元可以以GB2312,UTF-16,BIG5等各種編碼形式存在，那麼對開發人員來說，連進行最基本的字串列印、串連等操作都會寸步難行。例如一個GB2312的字串後面串連一個UTF-8的字串，那麼串連後的最終結果應該是什麼編碼的呢？你選哪一個都沒有道理。因此牢記下面這句話，這也是Java開發人員的共同意志：在Java中，字元只以一種編碼形式存在，那就是U