Question

我已经这样做了一段时间，但现在我开始思考了。

HttpServletRequest是Java标准中定义的接口。为什么我们总是需要一个具体的第三方定义，甚至是编译，如下所示（使用Apache）：

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>servlet-api</artifactId>
    <version>3.0.1</version>
    <scope>provided</scope>
</dependency>

这是否意味着编写使用javax.servlet的纯粹标准的，与供应商无关的代码是不可能的？

P.S。我知道我可以使用Glassfish而不是Apache。但这意味着我将使用另一个具体实现，而不是编码到一个通用接口。

P.P.S。让我进一步澄清我的问题。 HttpServletRequest接口（我不是在讨论实现）在Apache和Glassfish库中定义。一个获得Apache Software Foundation的许可，另一个获得Oracle的版权。是否存在规范的HttpServletRequest接口？

P.P.P.S。现在看起来我可以进一步完善我的问题。如果标准定义了一个接口如此紧密，以至于多个供应商之间没有可能的变化 - 为什么不将其作为标准库的一部分？为什么要允许多种事实来源？

Answer 1

但这意味着我将使用另一个具体实现，而不是编码到一个通用接口。

不，这完全不正确。向javax.servlet:servlet-api添加依赖项时，您指定要编码到公共接口。然后，您还必须为该接口的特定实现添加依赖项。

重点是开箱即用的java不可能包含所有可能的通用接口供您进行编码。因此，您必须获得您感兴趣的界面，然后您还必须为其获取特定的实现。

Answer 2

javax.servlet.http.HttpServletRequest - 它是Java EE的一部分吗？

是。 javax.servlet.http.HttpServletRequest是Java EE规范中定义的接口。阅读docs。

这是否意味着编写纯粹标准的，独立于供应商的代码哪个使用javax.servlet是不可能的？

当您使用实现此接口的任何类时，您正在编写与供应商无关的代码。这就是JEE将其作为接口包含的原因 - 每个兼容的servlet容器（Tomcat或Glassfish或Weblogic）必须遵守的合同。想象一下，一个不合规的容器提供了一个servlet api，它不遵守JEE规范中规定的合同。在这种情况下，您实际上必须编写依赖于供应商的代码来执行诸如从请求上下文中检索参数或检索与请求上下文关联的会话对象之类的操作。

然而，所有符合JEE规范的容器都实现了JEE规范中指定的接口（例如HttpServletRequest，HttpServletResponse）这一事实，您不必编写任何特定于供应商的代码，如果切换，它将会中断容器之间。

为什么没有javax.servlet.http.HttpServletRequest的规范定义？

2 个答案: