為什么JSP中存在scriptlet？

Question

我已經聽過十億次關於在JSP中使用Scriptlets（那些類似php的<% %>事物）的可怕性。

• 事實已經證明，Scriptlets打破了代碼設計模式，通常是MVC模式
• 許多J2EE框架（例如JSF 2.0+ ）已經禁用了scriptlet的使用。

由於任何用途都不需要scriptlet，並且可以用JSTL，其他標記庫和EL（表達式語言）替換它們，為什么它們仍然存在？ 為什么Oracle還沒有從JSP技術中刪除這些scriptlet呢？

Answer 1

這是三年前的問題，但我想就此事提出個人觀點。 我在大項目（CRM系統）中使用帶有scriptlet的JSP超過15年，這是我的經驗：

• Scriptlets只有在你允許的情況下才能打破MVC模式。 我不明白為什么<c:out ...${product.priceVat}>以某種方式比<%= product.getPriceVat() %>更好。 很多時候它實際上更糟糕。 它更冗長，你可能會丟失類型信息。 屬性priceVat BigDecimal還是帶有貨幣的格式化字符串？ 你有時候不知道EL（取決於使用的IDE）。
• 我們項目的大幫助是自動重構。 如果一個開發人員將getPriceVat方法重命名為getPriceTax則必須將其反映在所有代碼庫中。 IntelliJ IDEA非常適合處理scriptlet。 不確定它是否會自動將${product.priceVat}重命名${product.priceVat} ${product.priceTax} （編輯：它確實很酷）。 Netbeans或Eclipse不能很好地處理JSP sefactorings。
• Scriptlet的性能優於EL / JSTL組合。 他們必須看看引擎蓋下。 后者產生更大的代碼（Apache Jasper），我們在Java方法中運行64kB代碼限制幾次，並且實際上被迫用scriptlet替換一些標簽。
• 原型。 我們經常使用scriptlet對JSP進行原型化（類型代碼 - 刷新頁面 - 類型代碼 - 刷新...）。 稍后我們會增強我們的taglib並清理頁面。
• 熱修復。 我們通過直接更改生產服務器上的一個JSP scriptlet來阻止服務器重啟幾次。 如果您需要在類中更改已編譯的代碼並且需要重建整個WAR文件，則無法實現。 我知道這很討厭。
• 代碼縮進是scriptlet的噩夢。 這是使用scriptlet的明顯缺點。
• 我希望永遠不會棄用對scriptlet的支持。 能夠在web.xml中禁用scriptlet對於干凈的代碼純粹主義者來說應該足夠了。

Answer 2

它們仍然存在以實現向后兼容。