復雜性是指組合復雜性，這是當你將一個新特性與其他語言特性以任意可能的方式進行組合時所帶來的復雜性。Eckel認為他自己是一個"特性上瘾者"，總是思考語言在新特性方面的進化，但是現在他質疑如果一個特性不能被正確的實現，該特性是否應該被去掉 (例如Java的泛型)。是向後兼容C語言產生了語言復雜性和困難性。
最近，關於Java平台的未來有許多辯論，有些人認為Java應該加入更多的特征，這樣才能與C#、Ruby這樣的語言競爭，另一些人認為應該保持Java的穩定，以免變的過於復雜以至於難以使用。Bruce Eckel認為應該徹底停止往Java中增加新特性，這引起了一場新的辯論。
在Bruce Eckel 的博文中，他說如果Java要保持主流地位，那麼就需要停止進化。作為一種語言，Java已經“過於嘈雜”了，代碼有些過分啰嗦(例如System.out.println())。Eckel認為Java泛型增加了復雜性，這已經引起了人們的關注，他還說明了他看到的Java的一個關鍵問題：
我們對於復雜性的唯一控制手段是抽象：隱藏不需要暴露的部分(分治法("divide and conquer")是一個變種)。在Java中的悖論是，復雜性問題的一個關鍵方面被忽略了：沒有認識到代碼可讀性是重要的問題。好像IDE會為你寫代 碼，如果那樣的話即使代碼過分復雜也不是問題了。
[Joshua Bloch] 將關於復雜性的思想提升了一步。他說復雜 性不僅僅是指一個孤立的特定特征的復雜性，這種情況下復雜性通常是一目了然的。復雜性是指組合復雜性，這是當你將一個新特性與其他語言特性以任意可能的方式進行組合時所帶來的復雜性。如果你沒有從一開始就小心的設計，那麼當你將一個新特性加入一種現存的語言中時，你無法控制該特性是怎樣與其他現存特性進行 組合的。組合復雜性會產生恐怖的後果，特別是在加入了特性之後，這時再做任何事情都為時已晚。早餐結束後Josh說這類復雜性為Java的答疑解惑者提供 了豐富的素材，但是對於整個Java社區是有害的。
Eckel認為他自己是一個“特性上瘾者”，總是思考語言在新特性方面的進化，但是現在他質疑如果一個特性不能被正確的實現，該特性是否應該被去掉 (例如Java的泛型)。Eckel認為C和C++都非常穩定，Java也應該穩定而不是追逐新的語言特性或者試圖跟隨所有的市場沖動。有些人提出了打破 向後兼容性的想法，他們認為那些希望使用老特性的人們可以使用老版本的Java而不要升級到新版本。Eckel對於不惜一切代價維護向後兼容性的風險做了 警告：
如果由於向後不兼容而不能正確的插入特性，我們在語言變化的時候會受到很大束縛，Java現在的情形與C++相同。C++經常因 為它的設計受到批評，從C++標准委員會剛開始運轉我就在其中工作，已經工作了8年，我看到了所有關於語言特性的辯論。這些語言特性不是變化無常的，而是 經過非常謹慎的而且深思熟慮的考量的結果。是向後兼容C語言產生了語言復雜性和困難性。一旦你在所有事情上都把自己與向後兼容綁定在一起，那麼當你向語言 加入特性的時候必須做好語言被破壞的准備。如果Java不願意打破向後兼容性，那麼它就無法避免不打糧食的復雜性以及不完整的新特性實現。
Eckel認為新的語言是放置主要新特性的正確場所，Scala是“當前Java最好的退出策略”。他還認為Java唯一的出路是成為象C那樣的工具語言，將來只應該清理並豐富現在不完整的庫，把主要的語言變化(例如閉包)留給其他語言，而不是加入Java中。
Kevin Dangoor同意Eckel的觀點，他說在需要向後兼容性的語言中加入新的特性也是笨拙的，他還指出在這一領域ECMAScript與Java有同樣的問題。Dangoor還對於開發者始終要尋求新的、炫的特性來幫助項目的批判聲音提出了質疑：
軟件是思考的成果。其可鍛性很強且新的思想很容易測試。通過互聯網，新的思想和代碼傳播的很快很遠，這是好事情。對於我來說，現 在開發軟件比5、10、15、20年前要好的多。我看到許多閃光的事物飛過，而沒有真正的使用過它們。但是我認為這些閃光的事物是非常重要的，其中包含了各種各樣的思想，可以使用不同的工具將其應用於不同的場景。一些出自這些思想的實現成為了主流。
一般來說，人們不會轉而使用所有從其身邊 飛過的閃光的事物。有些人會認真的嘗試這些事物，他們可能會成為成功的拓荒者或者遭受失敗的痛苦而轉向其他解決方案。如果有足夠的人喜歡該思想並且推動它 的發展，那麼該思想會成為主流。Rails是2004年閃光的新事物。毫無疑問，有一些早期的使用者遭受了痛苦，但是在那些歲月裡，相對於使用其他工具的 人而言，更多的人因為使用Rails獲得了非常高的生產率。不管最終有多少人接受了Rails，事實是自Rails出現以後，它的很多思想對工作產生了顯 著的影響。
Cay Horstmann 同樣認為應該減少對Java語法的關注，增加對Java中痛苦之處的關注。Horstmann援引了C++，指出Java解決了C++碰到的兩個主要痛苦之處，內存管理和GUI/數據庫的訪問。
然而，Java現在需要解決它自己的痛苦之處：
臃腫的代碼 —— getter和setter方法，匿名類形式的事件監聽器，可以由編譯器推斷出來的長的類型聲明。
Web應用開發 —— 這很難，用復雜的而且動力不足的技術，例如JSP和JSF來開發web應用“就像用叉子來喝湯”。
並發 —— “我不夠聰明，不能滿懷信心的說我編寫的重要並發程序不會有死鎖，不會有競爭條件。這就象我不夠聰明，不能滿懷信心的說我編寫的重要C++程序不會有內存洩露或內存破壞”
其他觀點：
Phillip Cal?ado認為Java應該固定而不是繼續擴展，但是不同意關於Java本身難以閱讀的說法，他說在創建Java的時候，它比當時的語言，例如C++易於閱讀
Richard Relos認為 大多數Java代碼不使用新的語言特性，增加新的特性僅僅分散了開發者的注意力，破壞了邏輯形式。
Ian Cooper探討了C#的問題，他質疑C#是否已經到達了收益遞減的點，他同意主要新特性的去處應該是一個新語言
Giovani Salvador擔心如果Java不再增加新特性，它會過時，那麼Java開發者會變成“恐龍”
