为什么JSP中存在scriptlet？

Question

我听说过十亿次次在JSP中使用Scriptlets（那些类似php的<% %>事物）是多么可怕。

• 已经证明Scriptlet打破了代码设计模式，通常是MVC Pattern
• 许多J2EE框架（例如JSF 2.0+）已经禁用了scriptlet的使用。

由于任何用途都不需要scriptlet，并且可以替换为JSTL，其他标记库和EL（表达式语言），为什么它们仍然存在？为什么Oracle还没有从JSP技术中删除这些小脚本呢？

Answer 1

这是一个已有三年历史的问题，但我想对此事发表个人看法。在大型项目（CRM系统）中，我将JSP与scriptlet一起使用了15年以上，这是我的经验：

• 仅当您允许脚本时，它们才会破坏MVC模式。我不知道为什么<c:out ...${product.priceVat}>比<%= product.getPriceVat() %>更好。实际上，很多时候情况更糟。它比较冗长，您可能会松开类型信息。属性priceVat是BigDecimal还是具有货币格式的字符串？您有时不知道是否使用EL（取决于使用的IDE）。
• 我们的项目的最大帮助是自动重构。如果一个开发人员将getPriceVat方法重命名为getPriceTax，则它必须反映在所有代码库中。 IntelliJ IDEA非常适合处理脚本。不知道它是否自动将${product.priceVat}重命名为${product.priceTax}（编辑：确实可以，很酷）。 Netbeans或Eclipse不能很好地处理JSP分离。
• 小脚本的性能优于EL / JSTL组合。他们必须要看你的内幕。后者会产生更大的代码（Apache Jasper），并且我们在Java方法的64kB代码限制中运行了几次，实际上被迫用scriptlet替换了一些标签。
• 原型制作。我们经常使用scriptlet原型化JSP（类型代码-刷新页面-类型代码-刷新...）。后来，我们增强了标签库并清理了页面。
• 热修复。通过直接更改生产服务器上的一个JSP脚本，我们防止了几次服务器重启。如果您需要在类内部更改已编译的代码，并且需要重建整个WAR文件，则不可能。我知道这很讨厌。
• 使用小脚本，代码缩进是噩梦。这显然是使用脚本脚本的缺点。
• 我希望对脚本的支持永远不会被弃用。对于干净的代码纯粹主义者来说，禁用web.xml中的scriptlet的能力应该足够好。

Answer 2

它们仍然存在以实现向后兼容。