Java

Java程式可向一個伺服器發出一個CGI請求，這與HTML表單頁沒什麼兩樣。而且和HTML頁一樣，這個請求既可以設為GET（下載），亦可設為POST（上傳）。除此以外，Java程式還可攔截CGI程式的輸出，所以不必依賴程式來格式化一個新頁，也不必在出錯的時候強迫使用者從一個頁迴轉到另一個頁。事實上，程式的外觀可以做得跟以前的版本別無二致。代碼也要簡單一些，畢竟用CGI也不是很難就能寫出來（前提是真正地理解它）。所以在這一節裡，我們準備辦個CGI編程速成班。為解決常規問題，將用C++建立一些CGI

著作權：(xiaodaoxiaodao)藍小刀 xiaodaoxiaodao@gmail.comhttp://www.blogjava.net/xiaodaoxiaodao/articles/103469.html 轉載請註明來源/作者關於Web Start的JNLP Specification可以到sun網站http://java.sun.com/products/javawebstart/download-spec.html下載。 下面是用最簡單的HelloWorld方法實現一個Java

現在討論一下伺服器應用（程式）的問題，我把它叫作NameCollecor（名字收集器）。假如多名使用者同時嘗試提交他們的E-mail地址，那麼會發生什麼情況呢？若NameCollector使用TCP/IP通訊端，那麼必須運用早先介紹的多線程機制來實現對多個客戶的並發控制。但所有這些線程都試圖把資料寫到同一個檔案裡，其中儲存了所有E-mail地址。這便要求我們設立一種鎖定機制，保證多個線程不會同時訪問那個檔案。一個“訊號機”可在這裡協助我們達到目的，但或許還有一種更簡單的方

大家迄今看到的例子使用的都是“傳輸控制通訊協定”（TCP），亦稱作“基於資料流的通訊端”。根據該協議的設計宗旨，它具有高度的可靠性，而且能保證資料順利抵達目的地。換言之，它允許重傳那些由於各種原因半路“走失”的資料。而且收到位元組的順序與它們發出來時是一樣的。當然，這種控制與可靠性需要我們付出一些代價：TCP具有非常高的開銷。還有另一種協議，名為“使用者資料包通訊協定”（UDP），它並不刻意追求資料包

提起Java內部類（Inner Class）可能很多人不太熟悉，實際上類似的概念在C++裡也有，那就是嵌套類（Nested Class）， 關於這兩者的區別與聯絡，在下文中會有對比。內部類從表面上看，就是在類中又定義了一個類（下文會看到，內部類可以在很多地方定義），而實際上並沒有那麼 簡單，乍看上去內部類似乎有些多餘，它的用處對於初學者來說可能並不是那麼顯著，但是隨著對它的深入瞭解，你會發現Java的設計者在內部類身上的確是用

JabberServer可以正常工作，但每次只能為一個客戶程式提供服務。在典型的伺服器中，我們希望同時能處理多個客戶的請求。解決這個問題的關鍵就是多執行緒機制。而對於那些本身不支援多線程的語言，達到這個要求無疑是異常困難的。通過第14章的學習，大家已經知道Java已對多線程的處理進行了儘可能的簡化。由於Java的線程處理方式非常直接，所以讓伺服器控制多名客戶並不是件難事。最基本的方法是在伺服器（程式）裡建立單個ServerSocket，並調用accept()來等候一個新串連。一旦accept()

COM（以前稱為OLE）代表微軟公司的“元件物件模型”（Component Object

使用 ODFDOM 來建立文本、試算表和示範圖形文檔首先，我們簡要描述一 下 ODF 文檔結構。ODF 文檔儲存在一個 ZIP 壓縮包中，它包含 content.xml、 style.xml 及其他若干文檔。Content.xml 用來儲存文檔內容，style.xml 用來 儲存文檔樣式資訊。content.xml 檔案也含有一些樣式資訊，可以用來自動建立一些默 認值，如字型和顏色。一般來說，操作一個 ODF 文檔分四步：載入已有 ODF 文檔或建立 ODF 文檔。向 ODF

ODFDOM 分層模型概述ODFDOM for Java 為希望建立、訪問和儲存 ODF 文檔的開發人員提供一個輕量的 Java API，讓他們可以不必詳細瞭解完整的 ODF 標準規範。ODFDOM 採用層次化的多層結構，其中每個層有特定的用途。由於採用鬆散耦合的設 計，下面的層並不依賴於上面的層。圖 1 給出 ODFDOM 分層模型的結構。圖 1. ODFDOM 分層模型下面簡要解釋這些層：定製的 ODF 文檔 / 可擴充層。後面把這一層稱為定製層。儘管它不是 ODFDOM 包的

Open Document Format 概述ODF 是一種基於 XML 的開放標準檔案格式，適 用於試算表、文字文件和示範稿等辦公文檔。ODF 是應用程式中立、平台中立和廠商 中立的，因此有助於提高辦公文檔的互通性。ODF 標準由 Organization for the Advancement of Structured Information Standards (OASIS) 的 ODF Technical Committee 建立和維護。OASIS 於 2005 年 5 月發布了

利用JNI，可丟棄、捕捉、列印以及重新丟棄Java異常，就象在一個Java程式裡那樣。但對程式員來說，需自行調用專用的JNI函數，以便對異常進行處理。下面列出用於異常處理的一些JNI函數：■Throw()：丟棄一個現有的異常對象；在固有方法中用於重新丟棄一個異常。■ThrowNew()：產生一個新的異常對象，並將其丟棄。■ExceptionOccurred()：判斷一個異常是否已被丟棄，但尚未清除。■ExceptionDescribe()：列印一個異常和堆疊追蹤資訊。■ExceptionClea

本文的hadoop安裝是基於hortonworks的RPMS安裝文檔請見：http://docs.hortonworks.com/CURRENT/index.htmhttp://www.oracle.com/technetwork/java/javase/downloads/jdk-6u31-download-1501634.html下載java jdk-6u31-linux-x64.bin#Java settingschmod u+x /home/jdk-6u31-linux-x64.bin/

本文分為兩大部分，第一部分闡述了 FileNet Content Engine 的安全機制；第二部 分舉例說明了如何使用安全相關的 Java API 來設定安全，從而保證儲存內容的安全。FileNet Content Engine 安全機制簡介FileNet Content Engine 是 FileNet P8 體系中的核心模組之一，主要負責內容存 儲和內容管理。Content Engine 在一個物件導向的容器中提供了一系列服務來支援企業 內容管理和客戶自訂對象。Content

WebSphere MQ 中處理大訊息的方法使用過 WebSphere MQ 的讀者都知道，WebSphere MQ 對處理的單條訊息的大小是有限制的，目前支援的最大訊息是100M，而且，隨著訊息大小的增大，WebSphere MQ 處理的效能也會隨之下降。從最佳實務來說，WebSphere MQ 傳輸大小為幾K的訊息其效率是最高的。那如何使 WebSphere MQ 能高效的處理大訊息呢？WebSphere MQ 提供了處理大訊息的兩種方法：訊息分區和訊息分組。下面我們來看在使用 Java

引言IBM WebSphere Application Server 軟體提供了以下兩種機制，以支援 J2EE™ 應用程式開發人員在 Servlet 和 EJB 組件中安全地使用線程：非同步 BeanCommonj Timer and WorkManager for Application Servers 1.1 規範。兩種編程模式都允許您建立池線程和精靈線程，以便運行 J2EE

效果圖如下：源碼如下： package org.test;/*** <p>Title: LoonFramework</p>* <p>Description:拼圖影像處理[未最佳化]</p>* <p>Copyright: Copyright (c) 2007</p>* <p>Company: LoonFramework</p>* @author chenpeng　　*

在二維(2D)動畫中，通常需要按預定義的模式（有時稱為 控制路徑）在一個 2D 地區內移動對象。這種動畫需要解決兩個問題：如何指定對象要遵循的控制路徑。如何沿著所選的路徑移動對象。在本文中我們將為您展示如何用無損映像、Swing 技術和基於 Java 的動畫引 擎解決這些問題。我們將首先繪製所需要的動畫對象軌道，然後用動畫引擎驅動 對象沿著定義的控制路徑運動。可以容易建立和處理無損映像（在 下面說明），而且可以根據需要對使用它

Java的核心API是非常龐大的，這給開發人員來說帶來了很大的方便，經常人有評論，java讓程式員變傻。但是一些內容我認為是必須掌握的，否則不可以熟練運用java，也不會使用"就傻". 1、java.lang包下的80％以上的類的功能的靈活運用。2、java.util包下的80％以上的類的靈活運用，特別是集合類體系、正規運算式、時間、屬性、和Timer.

如何選擇Web開發架構開發架構的選擇，始終是個仁者見仁、智者見智的事情。尤其是Web層的開發架構，數量非常多，而且各有特色，如：Struts、WebWork、Spring MVC、Tapestry、JSF、WebPage3.0……等等。下面先來看看為什麼要使用Web開發架構一

引言在過去的幾乎整整十年中，人們編寫了很多有關 Java™ Platform, Enterprise Edition (Java EE) 最佳實務的內容。現在有十多本書籍 和數以百計（可能更多）的文章，提供了關於應該如何編寫 Java EE 應用程式的 見解。事實上，這方面的參考資料如此之多，並且這些參考資料之間往往還存在 著一些矛盾的建議，以至於在這些混雜的內容中進行學習本身也成為了採用 Java EE 的障礙。因此，為了給剛進入這個領域的客戶提供一些簡單的指導，我們彙編