時隔兩年仍然被點贊刷出來的回答
目前團隊主棧換java兩年了，一共做了四個項目涼了一個最大的。
我覺得只說開發不行是不客觀的，最近的項目被迫自己也進去參與了java代碼的調錯和維護。感受也挺深刻。
其實論項目本身，和18年前大多數B端業務公司做的項目差不多，劃幾個字塊系統基本都能一人處理完，技術難度真的沒啥。
底下評論有說Spring框架好的，我覺得Spring+ Mybatis也好，Hibernate也好，框架自身確實有著很好的技術力。如果大家都遵照規范去寫代碼，做個應用型項目并不難。但是呢，說真的哪怕開出了在本市對標同級高線的價格，面試量不少（兩年差不多面了200+），整體的水平還是嚴重拉胯。 比如做了半天新功能，時間點保證不了，臨上線了結果搞不清楚哪些數據表有修改，哪些數據表是存的框架數據等等（當然可以說這是管理啊規范問題，但是就兩個java做一個模塊的量都能混亂，開發的水平挺堪憂的）；或者一些關鍵接口設計明確要求精簡邏輯保證接口質量（比如防重啊，比如冪等），最后被用了一套堪比三次握手的冗雜方案完成，調試成本極高； 又比如在明確有清晰的前后端接口表的情況下，前后端聯調3個功能塊10來個接口竟然用了一周…
作為7年后端，我其實很難理解這些情況，并且認為是完全不應該發生的事情。 之前顧慮自己不是java，對java團隊放手一點，多盯成果就好，后來呢，自己受不了了先在git上審查代碼分析錯誤，然后發現做啥都IOC（框架要求，理解），以及生疏且晦澀的工廠模式，然后花了兩天學習用VScode搭環境（團隊用idea，太貴了），跑項目，把腳手架都熟悉了下用途，發現可能idea幫他們做了太多事了，上千個編譯警告里總有那么一兩個在sun jdk下是編譯不過去的，大量的泛型定義沒有給T類型，同一個語義的字段名稱和數據類型，在不同表/class中居然會不一樣造成極多的拆箱裝箱…
最致命的是，業務的邏輯代碼上，都是過程化調用了，沒有任何的入參校驗和調用結果檢查，例如一個關鍵接口，在其中的關鍵數據無法獲取時，仍然給調用方返回了success…
你說是語言問題嗎？不是呀。
你說語言沒問題嗎？我覺得好像也不是呀。像getter setter，一般都可以自動生成，結果框架常用slf4j做省略；1.8的stream()我在所有的面試里竟然沒有聽到一個回答的（即便它不好用）；用mybatis做數據表操作，聯表查詢很頭大（其實也就是寫sql，熟悉寫法也還好），底層數據結構要是不ok，一個controller里調用了十多次不同的sql才完成（并且是跨庫操作）； 最不舒服的一點，java是提供了匿名類型的，但是寫法也比較難受，幾乎沒見著其他人用，于是一些臨時的json對象定義，全靠map轉jsonArray，再轉json Object，難以控制數據提交的必填和可空。（也是因為用了這種形式，逼著前端的任何一個post調用，數據參數都必須按json對象的key- value模式來寫）。
是的，親自上手看過這些混亂的代碼和工程目錄（是啊 controller寫完了大多數的業務代碼，卻連基本的入參和返回值控制都罕見，service幾乎都是只調用同名的data Mapper）后，也能理解為什么做的慢，質量不足。
按照框架，做一個功能差不多涉及：data Mapper.xml，datamapper.java，interface，implement class，vo/po，controller。如果使用了什么模式，通常還有大量的abstract類在要維護。 一些能自動生成，大多數不能。此外還有各種注解要熟悉…
做一個測試，至少在VScode debugger里不能通過拖動運行點的方式讓代碼重新執行前幾條代碼，或者運行時修改，有些業務性很強的關聯api，做一次測試和修改再驗證，真的很費時間。
但是啊 本質上暴露的就是很多java開發離了框架什么都不會。按理必須更懂軟件要實現的業務目標的群體，現在更多變成了只知道輸入別人定義，輸出別人定義，邏輯歸產品經理考慮，測試還要交給測試的群體。
而他們還在拿著普遍偏高的工資。（最近面的十來個技術經理，20-30k*15，只有一個相對看好的，其他大多連初級的java基礎問題都會說不清楚 呵呵）
我相信如果團隊的角色高度健全，自動化流水線有跑，大家都開心，老板更開心，也可以通過壓低工作標準找低價的開發。反正等到隊伍健全到這個程度，多數開發就真的只是碼農了。
我個人覺得大力歡迎各位低階碼農繼續這么卷這么傲，那敬畏技術且認真的軟件工程師們才會真的迎來美好又有成就感的未來。到時候我們一定會銘記各位螺絲釘孜孜不倦一代更比一代卷的貢獻的。
以下為原回答
惡性循環？
能力優秀不應該高待遇么。
我自己在.Net技術棧工作5年，負責一個開發團隊，前一輪招聘時想著試試轉java，結果java的水貨太多。前端也是重災區，最后還是一口氣招了幾個.Net，不僅項目開展比預期好很多，還發現新人的接入成本降低不少。
總結了一下，.Net技術棧做的好的人，能做桌面程序能寫服務端，數據庫也基本上非常熟悉，頁面的js通常差不到哪去。這種全棧都比較通的人在java里很少遇到。另外.Net在早期的大多數團隊眼里都是需要大量造輪子的，一邊拖慢了業務開展的進度（老板眼里），但另一邊是工程師的平均能力都更強。仔細研究過.Net的全套技術體系的人都不難發現，設計的思想真的非常優秀，用來完成大型項目的效率并不會低。 java棧市場上更多還是各種框架使用者級別的碼農，如果要用“惡性循環”來評價，這個詞絕對輪不著.Net。
說回來，最終評價程序員優秀與否還是在于方案設計和落地的效率上，技術棧只是工具箱罷了。對我個人來說，同樣的價格，我絕對傾向知道怎么樣脫離Vs做.Net開發的人，而不是抱著一堆熟悉xx框架來面試的人。畢竟拿“框架不支持”來拒絕需求的更多還是來自j開頭的團隊【逃