java缺陷

A. java語言有哪些缺點

最大的缺點就是運行java程序需要裝java虛擬機. 就這一條嚴重的影像了java應用程序的使用,你基本看不到java的應用程序
還有就是java程序的運行成本比較高 過去機器配置不夠高的時候java顯得很慢 現在隨著java本身的版本升級和電腦性能的強化 這條基本已經不是問題了

B. java的缺點的什麼

Java的缺點很多。。。

我在這里簡單的說一下。。

第一: 運行速度慢，眾所周知，Java程序的運行依賴於
Java虛擬機，所以相對於其他語言(匯編,C,C++)編寫的程序慢，因為它不是直接，執行機器碼。

第二: 因為Java考慮到了跨平台性。所以他不能像語言
（例如:匯編,C) 那樣更接近操作系統。也就不能和操作系統的底層打交道了。但可以通過Java的JNI
(即Java本地介面。顧名思義：也就是利用Java語言調用，在當前系統上 其他的程序語言 "匯編或C等"所編寫的程序)技術，解決這一問題，但這只是解決了。一部分問題。

所以如果是你想開發 應用程序的話 最好選擇 Java以外的其他開發語言

C. java開發的缺點有哪些

我認為Java語言的10大問題是：
1、缺少閉包（closure）：我想這個不需要解釋了。函數式編程已經存在幾十年了，但最近幾年，它們獲得了越來越多的關注，最主要的原因，是它可以自然地編寫並行程序。我部分的同意Joshua Bloch強調在Java中引入閉包的問題需要再想一想（BGGA提議的方式真的很糟），至少閉包的缺失，使得在Java中做任何真正的函數式編程都是不可能的。
2、缺少一等函數：這個問題與前一個有些關聯，但我認為它更糟糕。在Java里，要達到類似效果的唯一方式，是使用著名的、醜陋悲慘的單方法匿名內部類，但這看上去的確是一個拙劣的方法。甚至在C#中，也通過代理機制，提供了一個更好的實現。
3、原生類型（Primitive types）：如果在Java中一切皆對象，那是多麼完美啊，但他們偏偏不這樣設計。因而，這一點導致了一些問題，比如，不能把一個int放到集合（Collection）里，這個在Java5中通過自動裝箱特性得到了解決（下面會提到）。它也造成了傳值與傳引用上的困擾，原生類型數據是通過值傳給方法的（復制一份拷貝，然後傳給函數），而真正的對象是通過傳遞（譯註：其實是復制對象地址再傳遞，因此應該也是傳值方式，只是由於函數內部可通過這個對象地址訪問對象，因此效果上類似傳引用）。
4、自動裝箱（Autoboxing）和自動拆箱（autounboxing）：這個特性是為了解決因原生類型的存在所導致的問題，在Java5引入的。它允許靜默地轉換原生類型到相應的對象，但這常常導致其它的問題。比如Integer可以為null，但int不能，因此這時JVM只能拋出一個難以調試的空指針異常（NullPointerException）。此外，它還可能導致其它奇怪的行為，就像下面的例子，我們就很難理解，變數test為什麼是false：
Intger a = new Integer(1024);
Intger b = new Integer(1024);
boolean test = a < b || a == b || a > b;
5、缺少范型具類化：范型是Java5引入的一個很酷的特徵，但是為了保持與舊版本Java的兼容性，導致缺失某些重要的特性，尤其是不能在運行時反省范型的類型。例如，你有一個方法，接受List參數，如果傳進來一個List，你卻不能知道運行里該范型的確切類型。同理，你也不能創建范型數組。這意味著，盡管下面的代碼看起來很自然，但卻不編譯不了：
List[] listsOfStrings = new List[3];
6、不可避免的范型警告：你有發現過自己陷入不可能去掉的關於范型的警告么？如果你像我一樣大量使用范型，我打賭你碰到過。事實上，是這個問題的規模化症狀，讓他們認為需要引入一個特定的註解(@SuppressWarnings("unchecked"))來處理這種情況，我覺得，范型應該可能被設計的更好。
7、不能傳void給方法調用：我得承認，這種給方法傳遞void的需求，乍一看有些怪異。我喜歡DSL，當我實現自己的DSL庫（lambdaj）的一個特定特性時，我不得不需要一個方法聲明成這樣的簽名：void doSomething(Object parameter)，這里為這個方法傳進來的參數parameter，是另一個方法調用的結果，它唯一的目的，是注冊調用（的對象）自身，以可以在以後執行它。讓我吃驚的是，即使println方法返回void，看上去也並沒有一個好理由，不允許我把代碼寫成這樣，：
doSomething(System.out.println("test"));
8、沒有原生的代理機制：代理是一種非常有效和應用廣泛的模式，但Java提供的代理機制，只針對介面，而不是具體類。這是為什麼象cblib這樣提供這種機制的庫，被如此多的主流框架，如Spring和Hibernate，採用的原因。此外，由於cglib通過運行時創建被代理類的子類來實現的，因此這些種方式有一個眾所周知的限制——不能代理final類，比如String。
9、差勁的Switch...case語句：Java規定，switch...case只能選擇int和enum（Java5開始）。這一點如果跟更現代的語言如Scala相比，看起來簡直太弱了。
10、受檢查異常（Checked exception）：類似原生類型，受檢查異常也已經成為Java的一個罪孽之源。它迫使程序員必須做下面兩件極其糟糕討厭的事情中的一個：讓你的代碼里充斥大量的、糟糕難讀的、容易出錯的try...catch語句，而這樣做的最大意義，只是將捕獲的異常，包裝成運行時異常，然後再重新拋出；或者是讓大量的拋出聲明子句污染你的API，讓介面缺少靈活性和可擴展性。
真正的問題是，這里我提到的這幾大主要問題，唯一的解決辦法，是要做一個痛苦的決擇，定義一套新的語言規范，放下當前版本的向後兼容性。我猜他們永遠也不會這么做，雖然我相信，如果編寫一個能夠自動轉換舊Java源碼的程序，讓它們與假設的新版本兼容，並不是很困難。最後，這就是我決定開始尋找一個更好的JVM兼容語言的原因。

D. java有什麼優點和缺點

Java是一種可以撰寫跨平台應用程序的面向對象的程序設計語言。Java技術具有卓越的通用性、高效性、平台移植性和安全性，廣泛應用於PC、數據中心、游戲控制台、科學超級計算機、行動電話和互聯網，同時擁有全球最大的開發者專業社群。
Java是功能完善的通用程序設計語言，可以用來開發可靠的、要求嚴格的應用程序。
java是純面向對象開發，功能強大，分支眾多，沒有java不能做的軟體。C/S也好B/S也好。從功能上講，沒有語言可以和java相比。
Java穩定，應用廣泛，一定時期內很難被其他編程語言取代;而許多大型系統都是用java開發，也不可能輕易使用其他語言。

同時，java還具有很多特點
1、跨平台性，雖然是很好的優勢，可以讓java在任何的系統中運行，但是前提是該系統要安裝java虛擬機，這樣導致一些java編寫的桌面程序無法在一般的用戶(沒有安裝java虛擬機的用戶)上使用
2、java的身後是sun公司，提供及時的api更新，但是過多的版本導致java的向下兼容性很差。而sun公司在j2ee上的標準定義的並不是完美，導致在j2ee的開發中多數使用開源框架，開源框架是好東西，但是更新速度並不快。
3、都說面向對象的語言先進與面向過程，java是oop語言，但是它適合的是bs系統，在web項目中java的實力毋庸置疑，但是轉到了底層的程序卻無法同c++抗衡。
4、個人認為java的最大優點是開源，但是這往往也成了最大的缺陷了，無法定義一個好的標准使得開發時使用了框架，在新的程序員來到公司時必須先了解框架，延緩了開發的時間。

所以java的前景應該是穩定而光明的。

E. java在編程上有什麼安全缺陷

在Java平台上進行多線程編程的缺陷

就其自身來說，並發編程是一種技術，提供了操作的同時執行，不論是在單一系統上還是分布在大量系統上。這類操作實際是一些指令順序，例如單獨某個頂級任務的子任務，這類操作能夠並行執行，或者是作為線程，或者是作為進程。線程和進程之間的本質區別在於：進程通常是獨立的(例如獨立的地址空間)，所以只能通過系統提供的進程間通信機制進行交互，而線程通常共享單一進程的狀態信息，能夠直接共享系統資源和內存中的對象。

可以使用下面兩種方法之一，通過多個進程來實現並發。第一種方法是在同一個處理器上運行進程，由操作系統處理進程之間的上下文環境切換。(可以理解，這種切換要比同一進程內多線程之間的上下文環境切換更慢。)第二種方法是構建大規模的並行和復雜的分布式系統，在不同的物理處理器上運行多個進程。

從內建支持的角度來說，Java 語言通過線程提供並發編程;每個 JVM 都能支持許多線程同時執行。可以用以下兩種方法之一在 Java 語言中創建線程：

繼承 java.lang.Thread 類。在這種情況下，已經重寫的子類的 run() 方法必須包含實現線程運行時行為的代碼。要執行這個代碼，需要實例化子類對象，然後調用對象的 start() 方法，這樣就可以在內部執行 run() 方法了。

創建 Runnable 介面的定製實現。這個介面只包含一個 run() 方法，在這個方法中，要放置應用程序代碼。要執行這個代碼，需要實例化實現類的對象，然後在創建新 Thread 時，把對象作為構造函數的參數傳入。然後調用新創建的線程對象的 start() 方法，開始執行控制的新線程。

線程安全性和同步

如果 Java 對象中的某個方法能夠安全地運行在多線程環境中，那麼就稱該方法是 線程安全的。要獲得這種安全性，必須有一種機制，通過該機制，運行同一方法的多個線程就能夠同步其操作，這樣，在訪問相同的對象或代碼行時，就會只允許一個線程被處理。這種同步要求線程使用叫作 信號 的對象彼此進行溝通。

有一種類型的信號叫作 互斥信號 或 互斥體。顧名思義，這個信號對象的擁有權是互斥的，也就是說，在任意指定時間，只有一個線程能夠擁有互斥體。其他想獲得所有權的線程會被阻塞，它們必須等待，直到擁有互斥體的線程釋放互斥體。如果多個線程按順序排隊等候同一互斥體，那麼在當前擁有者釋放它的時候，只有一個等候線程能夠得到它;其他線程將繼續阻塞。

在 1970 年代初，C.A.R. Hoare 和其他人共同開發了一個叫作 監視器 的概念。一個 監視器 就是一個代碼主體，它的訪問受到互斥體的保護。任何想執行這個代碼的線程，都必須在代碼塊頂部得到關聯的互斥體，然後在底部再釋放它。因為在指定時間只有一個線程能夠擁有互斥體，所以這就有效地保證了只有擁有它的線程才能執行監視器的代碼塊。(受保護的代碼不需要相鄰 —— 例如，Java 語言中的每個對象都有一個與之關聯的監視器。)

任何想在 Java 語言中進行線程編程的開發人員，都會立即把上面的內容當成 synchronized 關鍵字所帶來的效果。可以確保包含在 synchronized 塊中的 Java 代碼在指定時間只被一個線程執行。在內部，可以由運行時將 synchronized 關鍵字轉換成某一種情況：所有的競爭線程都試圖獲得與它們(指線程)正在操作的對象實例關聯的那個(惟一的一個)互斥體。成功得到互斥體的線程將運行代碼，然後在退出 synchronized 塊時釋放互斥體。

等候和通知

wait/notify 構造在 Java 語言的線程間通信機制中也扮演了重要的角色。基本的想法是：一個線程需要的某個條件可以由另外一個線程促成。這樣，條件的 wait 就可以得到滿足。一旦條件為真，那麼引發條件的線程就會 notify 等候線程蘇醒，並從中止的地方繼續進行。

wait/notify 機制要比 synchronized 機制更難理解和判斷。要想判斷出使用 wait/notify 的方法的行為邏輯，就要求判斷出使用它的所有方法的邏輯。一次判斷一個方法，把該方法和其他方法隔離開，是對整體系統行為得出錯誤結論的可靠方式。顯然，這樣做的復雜性會隨著要判斷的方法的數量增長而迅速提高。

線程狀態

我前面提到過，必須調用新創建的線程的 start() 方法來啟動它的執行。但是，僅僅是調用 start() 方法並不意味著線程會立即開始運行。這個方法只是把線程的狀態從 new 變成 runnable。只有在操作系統真正安排線程執行的時候，線程狀態才會變成 running (從 runnable)。

典型的操作系統支持兩種線程模型 —— 協作式和搶占式。在協作式 模型中，每個線程對於自己對 CPU 的控制權要保留多久、什麼時候放棄有最終意見。在這個模型中，因為可能存在某個無賴線程佔住控制權不放，所以其他線程可能永遠無法得到運行。在 搶占式 模型中，操作系統本身採用基於時鍾「滴答」的計時器，基於這個計時器，操作系統可以強制把控制權從一個線程轉移到另外一個線程。在這種情況下，決定哪個線程會得到下一次控制權的調度策略就有可能基於各種指標，例如相對優先順序、某個線程已經等待執行的時間長短，等等。

如果出於某些原因，處在 running 狀態的線程需要等候某個資源(例如，等候設備的輸入數據到達，或者等候某些條件已經設定的通知)，或者在試圖獲得互斥體的時候被阻塞，因此線程決定睡眠，那麼這時它可以進入 blocked 狀態。當睡眠周期到期、預期輸入到達，或者互斥體當前的擁有者將其釋放並通知等候線程可以再次奪取互斥體時，阻塞的線程重新進入 runnable 狀態。

當線程的 run() 方法完成時(或者正常返回，或者拋出 RuntimeException 這樣的未檢測到異常)，線程將終止。這時，線程的狀態是 dead。當線程死亡時，就不能通過再次調用它的 start() 方法來重新啟動它，如果那麼做，則會拋出 InvalidThreadStateException 異常。

四個常見缺陷

正如我已經展示過的，Java 語言中的多線程編程是通過語言支持的大量精心設計的構造實現的。另外，還設計了大量設計模式和指導原則，來幫助人們了解這種復雜性帶來的許多缺陷。除此之外，多線程編程會很容易地在不經意間把細微的 bug 帶進多線程代碼，而且更重要的是，這類問題分析和調試起來非常困難。接下來要介紹的是用 Java 語言進行多線程編程時將會遇到(或者可能已經遇到過)的最常見問題的一個列表。

爭用條件

據說 爭用條件 存在於這樣的系統中：多個線程之間存在對共享資源的競爭，而勝出者決定系統的行為。Allen Holub 在他撰寫的文章 「programming Java threads in the real world」 提供了一個帶有這樣 bug 的簡單的多線程程序示例。在沖突的訪問請求之間進行不正確同步的另一個更可怕的後果是 數據崩潰，此時，共享的數據結構有一部分由一個線程更新，而另一部分由另一個線程更新。在這種情況下，系統的行為不是按照勝出線程的意圖進行，系統根本不按照任何一個線程的意圖行動，所以兩個線程最後都將以失敗告終。

死鎖

死鎖 的情況是指：線程由於等候某種條件變成真(例如資源可以使用)，但是它等候的條件無法變成真，因為能夠讓條件變成真的線程在等候第一個線程「做某件事」。這樣，兩個線程都在等候對方先採取第一步，所以都無法做事。

活動鎖

活動鎖 與 死鎖 不同，它是在線程實際工作的時候發生的，但這時還沒有完成工作。這通常是在兩個線程交叉工作的時候發生，所以第一個線程做的工作被另一個線程取消。一個簡單的示例就是：每個線程已經擁有了一個對象，同時需要另外一個線程擁有的另外一個對象。可以想像這樣的情況：每個線程放下自己擁有的對象，撿起另外一個線程放下的對象。顯然，這兩個線程會永遠都運行在上鎖這一步操作上，結果是什麼都做不成。(常見的真實示例就是，兩個人在狹窄的走廊相遇。每個人都禮貌地讓到另一邊讓對方先行，但卻在相同的時間都讓到同一邊了，所以兩個人還都沒法通過。這種情況會持續一些時間，然後兩個人都從這邊閃到那邊，結果還是一點進展也沒有。)

資源耗盡

資源耗盡，又稱為 線程耗盡，是 Java 語言的 wait/notify 原語無法保證 live-ness 的後果。Java 強制這些方法要擁有它們等候或通知的對象的鎖。在某個線程上調用的 wait() 方法在開始等候之前必須釋放監視器鎖，然後在從方法返回並獲得通知之後，必須再次重新獲得鎖。因此，Java 語言規范在鎖本身之外，還描述了一套與每個對象相關的 等候集(wait set)。一旦線程釋放了對象上的鎖(在 wait 的調用之後)，線程就會放在這個等候集上。

多數 JVM 實現把等候線程放在隊列中。所以，如果在通知發生的時候，還有其他線程在等候監視器，那麼就會把一個新線程放在隊列尾部，而它並不是下一個獲得鎖的線程。所以，等到被通知線程實際得到監視器的時候，通知該線程的條件可能已經不再為真，所以它不得不再次 wait。這種情況可能無限持續下去，從而造成運算工作上浪費(因為要反復把該線程放入等候集和從中取出)和線程耗盡。

貪心哲學家的寓言

演示這種行為的原型示例是 Peter Welch 教授描述的「聰明人沒有雞肉」。在這個場景中考慮的系統是一所由五位哲學家、一位廚師和一個食堂組成的學院。所有的哲學家(除了一位)都要想想(在代碼示例中，考慮的時間是 3 秒)之後才去食堂取飯。而「貪心的」哲學家則不想把時間浪費在思考上 —— 相反，他一次又一次地回到食堂，企圖拿到雞肉來吃。

廚師按照一批四份的定量准備雞肉，每准備好一批，就送到食堂。貪心的哲學家不斷地去廚房，但他總是錯過食物!事情是這樣的：他第一次到的時候，時間太早，廚師還沒開火。因此貪心的哲學家只好乾等著(通過 wait() 方法調用)。在開飯的時候(通過 notify() 方法調用)，貪心的哲學家再一次回到食堂排隊等候。但是這次，在他前來等候的時候，他的四位同事已經到了，所以他在食堂隊列中的位置在他們後面。他的同事們把廚房送來的一批四份雞肉全部拿走了，所以貪心的哲學家又要在一邊等著了。 可憐(也可能是公平的) ，他永遠處在這個循環之外。

驗證的問題

一般來說，很難按照普通的規范對 Java 編程的多線程程序進行驗證。同樣，開發自動化工具對於常見的並發問題(例如死鎖、活動鎖和資源耗盡)進行完整而簡單的分析也不太容易——特別是在任意 Java 程序中或者在缺乏並發的正式模型的時候。

更糟的是，並發性問題出了名的變化多端、難於跟蹤。每個 Java 開發人員都曾經聽說過(或者親自編寫過)這樣的 Java 程序：經過嚴格分析，而且正常運行了相當一段時間，沒有表現出潛在的死鎖。然後突然有一天，問題發生了，結果弄得開發團隊經歷許多的不眠之夜來試圖發現並修補根本原因。

一方面，多線程 Java 程序容易發生的錯誤非常不明顯，有可能在任意什麼時候發生。另一方面，完全有可能這些 bug 在程序中從不出現。問題取決於一些不可知的因素。多線程程序的復雜本質，使得人們很難有效地對其進行驗證。沒有一套現成的規則可以找出多線程代碼中的這類問題，也無法確切地證明這些問題不存在，這些導致許多 Java 開發人員完全避開多線程應用程序的設計和開發，即使用並發和並行的方式對系統進行建模會非常棒，他們也不使用多線程。

確實想進行多線程編程的開發人員通常准備好了以下一個或兩個解決方案(至少是一部分)：

長時間艱苦地測試代碼，找出所有出現的並發性問題，誠心地希望到應用程序真正運行地時候已經發現並修復了所有這類問題。

大量運行設計模式和為多線程編程建立的指導原則。但是，這類指導原則只在整個系統都按照它們的規范設計的時候才有效，沒有設計規則能夠覆蓋所有類型的系統。

雖然知道的人不多，但是對於編寫(然後驗證)正確的多線程應用程序這一問題，還有第三個選項。使用稱為通信順序進程( Communicating Sequential Processes，CSP)的精確的線程同步的數學理論，可以在設計時最好地處理死鎖和活動鎖之類的問題。CSP 由 C.A.R. Hoare 與 20 世紀 70 年代後期設計，CSP 提供了有效的方法，證明用它的構造和工具構建的系統可以免除並發的常見問題。

結束語

在這份面向 Java 程序員的 CSP 全面介紹中，我把重點放在克服多線程應用程序開發常見問題的第一步上，即了解這些問題。我介紹了 Java 平台上目前支持的多線程編程構造，解釋了它們的起源，討論了這類程序可能會有的問題。我還解釋了用正式理論在任意的、大型的和復雜的應用程序中清除這些問題(即競爭冒險、死鎖、活動鎖和資源耗盡)或者證明這些問題不存在的困難。

F. Java開發有哪些不足之處

1、框架泛濫,相對VS而言缺少強大的IDE,JDK需要專門下載
2、IDE不需要了,eclipse強大到無以復加了.最大的缺點就是慢，開源東西太雜，什麼都能往上套，標准不一
3、在開發速度上相對另外2P（ASP.PHP）而言慢些
4、開發的時間一定會很長時間，效率不高啊，雖然有SSH框架，但是開發的時候真正用SSH的也不多。
5、相對而言，java運行速度慢，開發時間長
6、框架太多，開源的東西有多有雜，運行速度比其他的（例如：ASP)慢，初學者面對這么龐大復雜的體系結構，學習比較困難。

G. java面向對象程序設計有什麼缺點

這個問題好奇怪，問有什麼缺點？那應該是要跟其他什麼東西作比較
一般說面向對象程序設計的缺點都是和面向過程程序設計比較的
面向對象程序設計的主要缺點就是會讓人陷入一種設計深淵之中
什麼程序都想著要繼承，都想著要面向對象，容易忽略問題的本質，尤其是對象繼承，超過三層以後，整個項目的復雜度會變得非常高
簡單說就是面向對象會使人過度設計

H. Java 語言的缺陷有哪些

Java的問題和JavaScript的問題都是一樣的，很多operator定義的太沒正交性了。

譬如string的==和equals，譬如Integer的==和equals，譬如List<int>和List<string>反射後獲取它的類型，etc。

I. java的優勢與缺點

1、Java語言是簡單的。Java語言的語法與C語言和C++語言很接近，使得大多數程序員很容易學習和使用Java。另一方面，Java丟棄了C++ 中很少使用的、很難理解的、令人迷惑的那些特性，如操作符重載、多繼承、自動的強制類型轉換。特別地，Java語言不使用指針，並提供了自動的廢料收集，使得程序員不必為內存管理而擔憂。
2、Java語言是一個面向對象的。Java語言提供類、介面和繼承等原語，為了簡單起見，只支持類之間的單繼承，但支持介面之間的多繼承，並支持類與介面之間的實現機制（關鍵字為implements）。Java語言全面支持動態綁定，而C++ 語言只對虛函數使用動態綁定。總之，Java語言是一個純的面向對象程序設計語言。
3、Java語言是分布式的。Java語言支持Internet應用的開發，在基本的Java應用編程介面中有一個網路應用編程介面（java.net），它提供了用於網路應用編程的類庫，包括URL、URLConnection、Socket、 ServerSocket等。Java的RMI(遠程方法激活)機制也是開發分布式應用的重要手段。
4、Java語言是健壯的。Java的強類型機制、異常處理、廢料的自動收集等是Java程序健壯性的重要保證。對指針的丟棄是Java的明智選擇。Java的安全檢查機制使得Java更具健壯性。
5、Java語言是安全的。Java通常被用在網路環境中，為此，Java提供了一個安全機制以防惡意代碼的攻擊。除了Java語言具有的許多安全特性以外，Java對通過網路下載的類具有一個安全防範機制（類ClassLoader），如分配不同的名字空間以防替代本地的同名類、位元組代碼檢查，並提供安全管理機制（類SecurityManager）讓Java應用設置安全哨兵。
6、Java語言是體系結構中立的。Java程序（後綴為java的文件）在Java平台上被編譯為體系結構中立的位元組碼格式（後綴為class的文件）, 然後可以在實現這個Java平台的任何系統中運行。這種途徑適合於異構的網路環境和軟體的分發。
7、Java語言是可移植的。這種可移植性來源於體系結構中立性，另外，Java還嚴格規定了各個基本數據類型的長度。Java系統本身也具有很強的可移植性，Java編譯器是用Java實現的，Java的運行環境是用ANSI C實現的。
8、Java語言是解釋型的。如前所述，Java程序在Java平台上被編譯為位元組碼格式， 然後可以在實現這個Java平台的任何系統中運行。在運行時，Java平台中的Java解釋器對這些位元組碼進行解釋執行，執行過程中需要的類在聯接階段被載入到運行環境中。
9、Java是高性能的。與那些解釋型的高級腳本語言相比，Java的確是高性能的。事實上，Java的運行速度隨著JIT(Just-In-Time)編譯器技術的發展越來越接近於C++。
10、Java語言是多線程的。在Java語言中，線程是一種特殊的對象，它必須由Thread類或其子（孫）類來創建。通常有兩種方法來創建線程：其一，使用型構為Thread(Runnable) 的構造子將一個實現了Runnable介面的對象包裝成一個線程，其二，從Thread類派生出子類並重寫run方法，使用該子類創建的對象即為線程。值得注意的是Thread類已經實現了Runnable介面，因此，任何一個線程均有它的run方法，而run方法中包含了線程所要運行的代碼。線程的活動由一組方法來控制。 Java語言支持多個線程的同時執行，並提供多線程之間的同步機制（關鍵字為synchronized）。
11、Java語言是動態的。Java語言的設計目標之一是適應於動態變化的環境。Java程序需要的類能夠動態地被載入到運行環境，也可以通過網路來載入所需要的類。這也有利於軟體的升級。另外，Java中的類有一個運行時刻的表示，能進行運行時刻的類型檢查。
Java語言的優良特性使得Java應用具有無比的健壯性和可靠性，這也減少了應用系統的維護費用。Java對對象技術的全面支持和Java平台內嵌的API能縮短應用系統的開發時間並降低成本。Java的編譯一次，到處可運行的特性使得它能夠提供一個隨處可用的開放結構和在多平台之間傳遞信息的低成本方式。特別是Java企業應用編程介面（Java Enterprise APIs）為企業計算及電子商務應用系統提供了有關技術和豐富的類庫。