Ⅰ 高分100，一個簡單問題，java集成環境NetBeans IDE 各個文件夾都是干什麼的
文件夾：build-存放編譯後抄的class文件
nbproject-存放項目的具體配置文件
src-java源代碼存放文件夾
test-JUnit測試文件存放位置
Build.xml構建描述文件，因為Netbeans的編譯打包是基於ant的，build就是ant實現自動編譯打包的描述文件。
manifest.mf是打包的時候需要的一個清單文件，是對打包後的jar包中的文件的一個描述下文件。
original.java，.netbeans_automatic_build，這兩個文件不知道你用的什麼Netbeans版本，在我的版本中並未生成此文件。
build-impl.xml是對Build.xml文件的具體描述，Build.xml其實並未實現具體的ant構建腳本，具體是在該文件中實現的，如果你看過build.xml的源代碼，就會發現一句<import file="nbproject/build-impl.xml"/>，這你就知道是什麼意思了。
Ⅱ java中的JSR75 JSR135 JSR180 JSR184 JSR185是什麼意思
JSRs: Java Specification Requests 即Java規范要求
它是Java標准化組織（Java Community Process）提交給sun的java開發草案。
對於實時應用都有對應的JSR，比如現在幾乎不用的EJB，以前都有對應的JSR，它是一種對應應用的開發標准草案。即它都是對應現在的每個Java應用的，是一些工業標准。
如：
JSR75：J2ME（用於手機的Java）的文件系統操作，Jsr75分兩個部分，一部分是File，即本地文件系統，就跟Windos里的資源管理器一樣；一部分是PIM，說白了就是電話本之類的信息。
JSR180：SIP API for J2ME這個資源開發包，它提供了在J2me平台上開發SIP（會話啟動協議）應用的能力。SIP（Session Initiation Protocol）會話啟動協議是一個面向於網路電話和會議的的應用層的控制（信令）協議。可以把它看成主要是基於IP網路的多媒體通訊協議。我們可以在這個協議的基礎上構建包括多媒體視頻會議，IP電話，即時消息通知系統等應用在移動終端。
JSR135：Mobile Media API，Mobile Media API 是一個J2ME 設備的多媒體性能規范。其目標是實現J2ME 多媒體應用的通用性。
JSR184：J2ME Mobile3D API,高性能手機3D開發的api。即用於手機3D開發。
JSR185：《無線領域的JAVA技術規范》（Java Technology for the Wireless Instry即JTWI，JSR185）正是為了完成「建立一個標准來保證J2ME應用程序的跨平台性」這個使命而出現的。
以上都是用於手機Java應用的開發。
Ⅲ JDBC鏈接資料庫的方法有幾種各自的優缺點
本地 JDBC 框架JDBC 是基本的 Java 技術 API，允許訪問資料庫。它代表最低級別的持久性策略。本地框架各不相同，但大多數有著相似的特徵。大多數 JDBC 解決方案把所有的數據訪問包裝在數據訪問對象中，對象中包裝有一個關系表。從那裡，您可以把數據留在結果集或者選擇把結果集中的每一行映射到一個對象。Java 技術開發人員傾向於映射到輕值對象(light value objects)。一個特殊的替代方案是 Martin Fowler 的有效記錄設計模式，這種設計模式提供針對數據表中行的包裝程序。每一個有效記錄都有訪問每一列的方法，以及保存、刪除或更新行的方法。長處基於 JDBC 的解決方案提供良好的控制能力。您要寫更多的代碼來解決預料中的問題，但是您有訪問資料庫的所有權利，並且可以讓它只做您想要它做的事。純 JDBC 給予您非常好的靈活性。弱點關系資料庫和對象並不是一回事 —— 這里有一點分歧。您不得不處理一些面向對象的概念，如繼承。您還必須自己管理每一個對象，寫查詢程序來完成創建、讀取、更新或刪除操作。如果要提升性能，需要提供您自己的緩存。總結對於那些技術不好但了解 SQL 的 Java 程序員來說，JDBC 是一個很好的選擇。如果您需要更好的訪問 SQL 或者在進行批處理計算或報告，那麼 JDBC 也能勝任。變種有幾個框架和工具可以幫助您擴展 JDBC。一些工具，像 Velocity 和 MiddleGen，會生成數據訪問對象，給出資料庫表的描述。Spring 提供依賴注入和面向方面的編程，這使得服務和依賴關系的集成更加容易。但是總得來說，應用程序結構和策略應該保持一致。對象關系映射程序OOP 和關系資料庫基於根本不同的基礎。通常，很難把兩者混合起來。如果您有一個現有的關系模式或一個可能頻繁改變的關系模式，那麼 ORM 框架也許正是您需要的。大多數的 ORM 試圖讓您透明地處理對純慶旅象。您提供一個 POJO，然後，通過使用代碼生成(EJB)、位元組碼操縱(JDO)或反射(Hibernate)，框架與持久性相關聯。每種技術都有它的長處和弱點，因此大多數的框架使用多種方法來完成工作。您需要告訴應用程序如何映射資料庫表到應用程序的類。您可以用一個獨立的 XML 文件或程序代碼中的注釋來達到目的。這些注釋可以採取 Java 5 注釋的形式(使用 XDoclet 之類的工具)。如果模式和對象模型不會走到一起，我一般會將代碼和配置文件分離。持久性框架讓您從資料庫載入一系列的對象。您可以顯示它們，或操縱它們並把它們存回到關系資料庫。大多數的 ORM 框架提供擴展，比如兩級緩存。一般來說，第一級緩存保證事務的完整性，第二級保證跨集群中機器的一致性。盡管有多種實現，但是您應該准確理解緩存策略。您需要用於管理配置和依賴性的策略。您的應用程序可能需要選擇一個事務策略並使用數據源和連接池。正如在前面的章節中所學到的那樣，Spring 和 ORM 能很好地為您處理這些問題。這里有一些可用的 ORM。EJB企業級 JavaBean 提供兩種標准化的持久性策略，EJB 1.x 標准 和 2.x 標准。第二個標准做的更好，但仍然過於復雜。EJB 專家組承認這一事實並將提供第三個標准，即 EJB 3 JSR;但是該標准將對所有的 Java Enterprise Edition (JEE) 用戶可用，不僅僅是對 EJB 用戶可用。因此，EJB 持久性標准實際上是一條死路，因為新的應用程序想要目差鎮標方案做凳接近期望的 JSR 220 標准。HibernateHibernate 很快變成了持久性的事實上的標准。它快速，有效，而且是免費的。因為 Hibernate 讓您制定任意的 POJO 持久性，所以它必須有一種方法把持久性關聯到一個對象而不必改動代碼。Hibernate 主要通過反射來提供透明性，但是它通過動態代理混合在一些運行時位元組碼操縱中。使用反射，Hibernate 可以在事務完成前後查看對象的狀態。如果狀態發生改變，Hibernate 可以把它保存到資料庫中。代理幫助 Hibernate 實現一些其他的特性，比如懶散載入(lazy loading)。(把動態代理想像成一個坐在目標對象前面的對象，它有一個與目標對象相同的介面。每當您調用某些方法或訪問實例變數時，代理都可以自由地調用持久層。)Hibernate 僅支持關系資料庫，而且它與 SQL 結合的緊密程度比大多數其他的持久性框架要高。Hibernate 使用類似於 SQL 的查詢語言，這種相似性對用戶的幫助很大。如果需要，您也可以在 Hibernate 中直接使用 SQL。像 JDO 一樣，Hibernate 擁有兩級緩存。第一級緩存叫做會話，給您一個存放持久性對象的地方。您可以把對象載入緩存並操縱它們。然後決定何時通過在會話上調用刷新(flush)或提交(commit)來將更改持久存儲到資料庫中。Hibernate 幫助您管理關系。如果您定義一個關系，比如雇員屬於部門，Hibernate 將對其進行管理。如果您載入一個部門的信息，您可以決定是在載入一個部門時載入所有的雇員信息(熱切載入)，還是等待載入雇員信息(懶散載入)。長處Hibernate 有一個靈活的映射機制。一些場景比其他場景付出更多的努力來映射，但是如果您能在一個關系模式中表示它，那麼也許在 Hibernate 中有一種方法來映射到它。Hibernate 的性能比大多數的框架要好而且還在不斷提升。文檔很優秀，收購 JBoss 後，支持也在改善。JBoss 小組也把 Hibernate 放置在一個合適的位置以搶在競爭者之前實現 JSR 200 持久性標准。對 Hibernate 來說，與其他開放源碼框架和商業框架的集成比其他的替代框架要好。一般來說，Spring 與 Hibernate 的集成比與其他任何一個持久性框架的集成要好。Hibernate 是一個創新的框架。在推動與 SQL 的集成上，它比大多數其他的框架走的更遠。它具有一些其他框架不支持的特性，比如會話過濾。還有一支強大的公共和商業開發人員團隊為其工作。弱點如果您是一家大公司，那麼您可能要用不支付許可費來彌補支持上的欠缺。Hibernate 比替代框架更加難以管理。例如，您沒有 SolarMetric 的 Kodo JDO 產品提供的豐富的管理控制台。您也沒有 Versant 的 JDP 產品提供的豐富的用戶界面工具。最後，Hibernate 不像一些持久性框架那麼專業。例如，對於一些邊緣情況，比如管理懶散載入，Kodo JDO 有非常好的錯誤信息和更加可預測的行為。JDO如果您想要帶持久性框架的 Betamax，JDO 1.x 就足夠了 —— 雖然時運似乎在轉向 JDO 2，更不用說 JSR 220 持久性標准了。在過去三年左右的時間里，最好的技術持久性框架來自 JDO 社區。JDO 通過位元組碼增強機制實現了透明性。JDO 2 多少會放鬆這個限制。JDO 提供一種叫做 JDO QL 的查詢語言。對緩存和提取定義了懶散/熱切提取場景的組(可以在每次查詢的基礎上定義這樣的場景)，它有正式的性能擴展。JDO 還為分離式處理(detached processing)提供一個模型，以便您能夠從一個 JDO 會話(叫做 PersistenceManager)分離一個對象，改變並重新附加該對象。然後資料庫應用所有更改。JDO 還為任意的數據存儲提供透明的持久性。在現實世界中，大多數的數據是非關系型的，JDO 自己就能很好地為該社區提供解決方案。長處JDO 的各種供應商各有長處。Kodo 產品在需要極限持久性場景的利基市場賣得很好。Kodo 執行快速，並得到廣泛的認同：它對任何一個 JDO 產品都有最好的映射支持。(我要說，就現在來看，它的映射支持是業界最好的。)Kodo 還在可管理性方面領先。(Versant 產品也有著非常快的速度。)顯然，它的最大優點是針對映射支持的用戶界面。弱點對 JDO 弱點的任何處理都必須從市場份額開始。作為一個標准，JDO 應當得到更好的保護，但是到目前為止，這個標准並不是非常成功。具有諷刺意味的是，JSR 220 持久性標準的出現很可能會對 JDO 造成打擊。許多 JDO 供應商已經宣布在他們的產品中支持 JSR 220。您將會看到一個更強大的標准，而且好的 JDO 供應商將能夠在那些市場中佔有一席之地。JSR 220 標准將會開放，而且新的標准將從那裡快速產生，您將會看到顧客使用同樣的標准來嘗試 JDO。由於疲弱的市場表現， JDO 需要在開放源碼社區中更好地表現。Versant 向 Eclipse 小組捐贈它的產品是在正確的方向上前進了一步。其他Top Link、OJB 和 Cayenne 正在追趕 Hibernate，但是它們不可能趕上了(出於許多因素)。在接下來的幾期文章中，我將用其他的語言如 Ruby 或 Python 來探索幾個框架。混合解決方案本文將在介紹完一種混合解決方案後結束。大多數的 ORM 解決方案把一個類映射到一個關系資料庫模式，而諸如 iBATIS 之類的混合框架則把類映射到一個 SQL 查詢的結果。對於 iBATIS，您提供一個 XML 文件，它指定查詢和從那些查詢到對象的映射。您能得到 ORM 的一些好處，比如一致緩存策略、獨立於代碼庫的 SQL 和限定的關系管理。長處iBATIS 還有一些 ORM 框架沒有的優點。您有對 SQL 的嚴格控制的權利，不必擔心對象/關系的不匹配，也不必投入幾個月來學習一個對象/關系映射框架。弱點iBATIS 不會給予您 ORM 所做的一切。您需要編碼查詢來完成每一次的資料庫訪問，而不是您自己來完成訪問。與資料庫的結合更加緊密。並依靠您選擇的 SQL 方言。然而這並不是 iBATIS 的直接局限，這些是這一類解決方案固有的本性。