Java 一切都是抽象的吗？

我是JavaEE新手，在理解JavaEE是如何实现的方面有些困难。根据我所使用的资源，我了解到JavaEE只是一组规范，而应用服务器是这些规范的真正实现

这是否意味着oracle的架构师刚刚提出了设计（只是框架：即接口、抽象类、类），而应用服务器（Glassfish、WebLogic）程序员用真实代码实现了这一点

JavaEE中的一切都只是规范吗

---

那么JPA、JAX-RS呢？这是否意味着应用服务器供应商没有实现这些规范的代码？如果是，这是否也意味着应用服务器供应商选择了规范的一个子集并用实际代码实现了它，而留下一些其他规范由其他供应商实现？

抽象接口（API）

抽象接口允许您将代码编译成class/jar/war，而无需知道或需要在要部署到的服务器上的确切实现。抽象接口通常由一个标准（JEE、JCP）组成

通常，这些接口被打包到只在编译时使用的库中（确保您的代码可以编译），而不将它们包含在war分发中。在运行期间，在服务器上，我们将使用任何已经可用和预安装的内容

使用maven依赖项，这是通过提供

提供的

作用域来实现的，这会导致库从打包（war文件）中排除

接口通常被命名为

*-api

，类似于

java.faces-api-2.2.jar

实施

在服务器端，我们通常已经使用实际实现作为应用服务器的一部分提供了库。它是一个标准的实现

通过将具有抽象接口（标准）的库与具有特定实现的库分离，您将避免根据特定于供应商的API进行编译

---

如果缺少该实现，您可以选择在服务器上手动安装它（将jar复制到正确的位置），或者使用

运行时

范围将其作为maven依赖项提供。在这种情况下，Maven将使库成为打包（war）的一部分，但从不针对它们进行编译。在这种情况下，您仍将使用提供的

范围提供api。
除了nice@JoD.的答案之外，还有一些想法：

JavaEE只是规范和应用程序的集合
服务器是这些规范的真正实现

没错

这是否意味着甲骨文的架构师刚刚提出了这个设计

确切地说，Sun的建筑师：）

那么JPA、JAX-RS呢？这是否意味着，应用服务器供应商
没有实现这些规范的代码

不需要。每个应用服务器都应该实现所有规范，以符合JavaEE。它们将如何实施，这是特定于供应商的。例如，WildFly的JPA实现是，但Glassfish使用。它们都是JPA的超集，因此，如果您只使用实现JPA的类，那么您可以确定您的应用程序可以部署在各种应用程序服务器上，而无需任何其他操作。但是，如果您使用来自例如
org.eclipse.persistence.*
包的类，那么您将无法在WildFly上部署，除非您将EclipseLink实现与应用程序一起提供。
基本上是的，EE只是规范。但通常（总是？）他们也会发布所谓的规范参考实现。如果其他供应商想声称受到EE投诉，他们必须通过测试，例如，不，在oracle记录之前，它是经过编程测试的。JAX-RS、JAX-WS、JPA等也是如此……例如，GlassFish是大多数JEE api的参考实现。您的意思是称为“-api.jar”的jar不包含实现代码，只包含框架吗？那么我们从哪里获得实现代码“-api.jar”通常包含框架代码。对于需要填写（实现）的部分，您可以购买许可证或使用开放源代码。通常还有一个参考实现（有时从开源中挑选）。例如，如果您使用JBoss，您不必担心jee和JavaFaces的实现，它就在那里。