有什么可以用 Servlet 而不是 JSP 实现的，反之亦然答案

【问题标题】：Is there anything that can be implemented with Servlets and not with JSPs or vice versa有什么可以用 Servlet 而不是 JSP 实现的，反之亦然
【发布时间】：2011-12-28 16:28:39
【问题描述】：

我们知道 JSP 被转换为 Servlet，Servlet 用于业务逻辑，而 JSP 用于视图等。。但从理论上讲，您可以使用 servlet 完成大部分使用 JSP 所做的事情。反过来也是一样。

但是有没有什么可以用 Servlet 而不是用 JSP 实现的，反之亦然？

前段时间我在一次采访中得到了这个问题，但经过大量谷歌搜索后没有找到任何答案。

【问题讨论】：

标签： java jsp jakarta-ee servlets

【解决方案1】：

据我所知，JSP 专门用于 HTTP 协议。我们不能将 jsp 用于任何其他协议实现。但是协议特定的 servlet 我们可以创建只是继承（实现/扩展）相应的基本协议类。在正常情况下（HTTP协议实现）我们也可以通过JSP实现servlet提供的所有便利。

【讨论】：

【解决方案2】：

所说的（从技术上讲，没有什么是 servlet 可以做而 JSP 不能做的，反之亦然）是正确的，但我相信面试官正在寻找的答案是 JSP 只适合用于文本输出，而 servlet 可以轻松输出文本或二进制数据。

【讨论】：

JSP 仅适用于文本输出*，但您可以使用 jsp scriptlet 中的 **JSP 轻松输出二进制数据。
您说得对，您可以使用 JSP 返回二进制数据，但这不是预期用途。因此我使用了“合适”这个词。 :) 我可能是错的，但我的猜测是面试官问的是两者中的哪一个在哪些情况下是合适的，对于知道最终他们在技术上都有能力做同样事情的候选人会加分。

【解决方案3】：

但是有什么可以用 Servlet 而不是用 JSP 实现的，反之亦然？

从技术上讲，没有什么可以由他们中的任何一个来实现。

在功能上，当您遵循 MVC 设计模式并在 servlet 中实现控制器部分和在 JSP 中实现视图部分时，在可维护性方面存在巨大差异。 Servlet API 提供了更清晰的抽象来挂钩特定的 HTTP 方法并在将任何位写入响应之前控制请求/响应。反过来，JSP 是响应的一部分，这会使某些任务更难实现，例如在发生异常时更改响应。

另见：

【讨论】：

jspInit() 方法可以与web.xml 中的<load-on-startup> 结合使用。但不鼓励这样做，与 scriptlets 一起使用。您应该为此使用 Servlet。或者更好的是ServletContextListener。毕竟，这关乎正确的设计和使用正确的工具来完成工作。
但问题不在于你是否应该，而在于能力。
以上是关于是否可以在应用程序启动时初始化 JSP 的问题的评论回复，但 OP 删除了评论。 @Dave：阅读我答案的第一段。我必须对此进行扩展吗？
我做了（句子），然后下一段没有；）
... 随便。我的观点仍然存在；如所问，OP 的帖子是关于能力，而不是智慧。

【解决方案4】：

虽然从技术上讲没有什么可以阻止你这样做，但在没有 UI 的情况下使用 jsp 会让我觉得这是徒劳的一课。 servlet 不仅可以用于传递网页，它还可以通过Apache HttpClient 和Spring remoting 之类的方式用作简单的远程处理机制。

【讨论】：

OP 并不是说您应该使用 JSP 进行远程处理，只是询问功能。

【解决方案5】：

两者之间存在一些细微差别：

生命周期不同，JSP 被翻译成文档形式（从 JSP 文件形式），然后再到 Java 类文件（.java 文件）。从这里开始，它们被视为 servlet（已编译等）。

JSP 还具有 Servlet 不可用的 Page 范围。

就可重用性而言，JSP 与 Servlet 不同。 JSP 可以使用 TagFile 和 TagLibraries 作为可重用的逻辑单元，这是 servlet 无法做到的。

【讨论】：

不正确。不同的生命周期不会改变技术能力。页面范围可以使用 servlet 方法中的方法局部变量来实现。 tagfiles/taglibraries 可以使用RequestDispatcher#include() 委托给一个不同且可重用的 servlet 来实现，该 servlet 直接写入响应。参见例如stackoverflow.com/questions/3024949/…
是的，同意，如果您愿意，您可以制作自己的 servlet 引擎，将 Servlet 转换为 JSP 代码，这样它们的工作方式相同。我说的是在不进行黑客攻击的情况下存在的差异。看看 Play 框架，你甚至没有编译类（.class 文件）的概念，尽管它确实适用于 Servlet API（某些部分）。
“黑客”是可能的并不意味着不可能以错误的方式进行。但是，您建议使用 servlet 是不可能的。
先生，您真的很喜欢争论这些问题，就像我以前看到的那样。这次我就不做了，太浪费时间了。我的答案就在那里，我们俩的cmets也是，我想任何人都可以得出必要的结论。根据您的论点，在第 3 版规范下，servlet 可以通过注释进行配置，而 JSP 仍然不能构成差异，因为您可以通过字节码修改从 JSP 编译中获得的类并编织注释配置。因为“有可能”
肯定存在功能差异，我什至在我的回答中详细阐述了这一点，但是 OP 要求提供技术差异。 “使用 JSP 可以实现 Servlet 无法实现的事情，反之亦然”。好吧，什么都没有。

【解决方案6】：

唯一的区别是 JSP 可以由不了解 Java 的文档编写者编写。

除此之外没有区别。

【讨论】：