AssertJ是一个Java库，它为断言提供了一个流畅的接口，这使得在测试代码中传递意图变得很容易。AssertJ提供可读的错误消息、软断言以及改进的集合和异常支持。我们的许多团队选择AssertJ作为默认的断言库，而不是将JUnit与Java Hamcrest结合使用。

AssertJ核心网站已转移到https://assertj.github.io/doc/

 

丰富和易于使用

AssertJ提供了一组丰富的断言，真正有用的错误消息，提高了测试代码的可读性，并被设计为在您喜欢的IDE中非常容易使用。

马上开始一分钟的入门指南，看看AssertJ的一些伟大的功能或保持最新的发布。

如果您相信AssertJ，您可以自动将JUnit断言转换为AssertJ。

可扩展的

您可以轻松地为自己的类编写断言，这将使您的测试断言反映领域，并且是在测试中使用通用语言的一种方法!

我们提供了一个断言生成器来快速创建域模型类的断言。

社区驱动的

AssertJ的存在只是为了帮助开发社区。我们倾听用户的想法，提供最有用的断言。

AssertJ是不再维护的great Fest Assert库的一个分支。

AssertJ将永远保持开放和自由。

AssertJ为流行的库提供断言

Guava

为类似于Multimap, Table, Optional or ByteSource.的Guava类型提供断言。

检查AssertJ Guava断言的最新消息和文档。

 Joda Time

为诸如DateTime和LocalDateTime之类的Joda时间类型提供断言。以后会有更多的，欢迎投稿!

检查AssertJ Joda时间断言最新的新闻和文档。

Neo4J

为节点、路径和关系等Neo4J类型提供断言。

检查AssertJ Neo4J断言的最新消息和文档。

Neo4J断言是由Florent Biville开发的。

原文：http://joel-costigliola.github.io/assertj/index.html

 

介绍

由于附加功能的建立，Spring 框架的结构在过去几年中变得明显更加复杂。现在，开始一个新的 Spring 项目需要一个漫长的设置过程。 Spring Boot 的发明是为了节省时间并避免在每个新项目中从头开始配置这个框架。

什么是 Spring 框架

Spring 是用于开发企业应用程序的最广泛使用的框架之一，它提供了健壮的编程和配置模型。这个框架的创建是为了简化 Oracle 流行的 Java EE 技术堆栈上的应用程序开发，当时该技术非常复杂且难以使用。

与其他框架不同，Spring 专注于应用程序功能的几个领域，并为它们提供了广泛的附加功能。

Spring Framework 的主要优点之一是它使用了依赖注入模式。 DI 使实现应用程序所需的功能变得更加容易，并允许开发松散耦合、更通用的类。

Spring框架的优点

让我们看一下 Spring Framework 的一些优点：

Spring Framework 可用于 Web 应用程序开发中使用的所有架构层；

• 编写类时使用非常轻量级的POJO模型；
• 允许您自由链接模块并轻松测试它们；
• 支持声明式编程；
• 消除了独立创建工厂和单例类的需要；
• 支持多种配置方式；
• 提供中间件级别的服务。

尽管 Spring Framework 有许多优点，但配置它所涉及的冗长准备过程促成了 Spring Boot 的创建。

用于应用程序开发的 Spring Boot

尽管 Spring Framework 具有优势，但作者决定为开发人员提供一些实用程序，这些实用程序可以自动执行配置过程并加快创建和部署 Spring 应用程序的过程。这些实用程序以 Spring Boot 的通用名称组合在一起。

虽然 Spring Framework 专注于提供灵活性，但 Spring Boot 旨在减少代码长度并简化 Web 应用程序开发。通过利用注释和样板配置，Spring Boot 减少了开发应用程序所需的时间。此功能可帮助您以较少或几乎没有配置开销创建独立应用程序。

易于依赖管理

为了加快依赖管理过程，Spring Boot 为每类基于 Spring 的应用程序隐式打包所需的第三方依赖，并通过所谓的启动包（spring-boot-starter-web、spring-boot-starter-数据-jpa 等）。

入门包是可以包含在应用程序中的方便依赖描述符的集合。它们允许您获得所有 Spring 相关技术的通用解决方案，无需搜索代码示例并从中加载所需的依赖项描述符。

例如，如果您想开始使用 Spring Data JPA 访问您的数据库，只需在项目中包含 spring-boot-starter-data-jpa 依赖项即可完成（无需寻找兼容的 Hibernate 数据库驱动程序和图书馆）。

如果你想创建一个 Spring Web 应用，只需要添加 spring-boot-starter-web 依赖，它会将开发 Spring MVC 应用所需的所有库拉到你的项目中，例如 spring-webmvc、jackson-json、validation -api 和 Tomcat。

简而言之，Spring Boot 是用来做什么的，它收集所有常见的依赖项并将它们定义在一个地方，这使开发人员可以立即开始工作，而不是每次创建新应用程序时都重新发明轮子。

因此，在 Spring Boot 中使用时 pom.xml 文件包含的行数比在常规 Spring 中少得多。

自动配置

Spring Boot 的优点之一，值得一提的是应用程序的自动配置。

选择合适的启动包后，Spring Boot 将尝试根据您添加的 jar 依赖项自动配置您的 Spring 应用程序。例如，如果添加 Spring-boot-starter-web，Spring Boot 会自动配置已注册的 bean，例如 DispatcherServlet、ResourceHandlers 和 MessageSource。

如果您使用的是 spring-boot-starter-jdbc，Spring Boot 会自动注册 DataSource、EntityManagerFactory 和 TransactionManager bean，并从 application.properties 文件中读取数据库连接信息。如果您不打算使用数据库并且不提供任何有关手动连接的详细信息，Spring Boot 将自动在内存中配置数据库，而无需您进行任何额外配置（如果您有 H2 或 HSQL 库）。使用用户首选项可以随时完全覆盖自动配置。

对应用服务器的原生支持——Servlet 容器

每个 Spring Boot 应用程序都包含一个嵌入式 Web 服务器。开发人员不再需要担心设置 servlet 容器并将应用程序部署到其中。应用程序现在可以使用内置服务器将自身作为可执行 jar 文件运行。如果您需要使用单独的 HTTP 服务器，只需排除默认依赖项即可。 Spring Boot 为不同的 HTTP 服务器提供了单独的启动包。

使用嵌入式服务器构建独立的 Web 应用程序，不仅方便开发，而且是企业级应用程序的有效解决方案；更重要的是，它在微服务领域变得越来越有用。将整个服务（例如用户身份验证）快速打​​包到独立且完全可部署的工件中的能力，该工件还提供 API，这使得安装和部署应用程序变得更加容易。

Spring Boot 是下一代工具的一部分，可简化 Spring 应用程序的配置过程。它不是自动生成代码的工具，而是项目构建自动化系统的插件（支持 Maven 和 Gradle）。

该插件提供了测试和部署 Spring 应用程序的功能。 mvn spring-boot:run 命令在端口 8080 上运行您的应用程序。此外，Spring Boot 允许您将应用程序打包到一个单独的 jar 文件中，并嵌入完整的 Tomcat 容器。这种方法是从 Play 框架的应用程序部署模型中借用的（不过，Spring Boot 也可以创建传统的 war 文件）。

Spring Boot 的主要优势之一是基于类路径的内容配置资源。当涉及到默认配置时，Spring Boot 非常直观。您可能并不总是同意它的设置选择，但至少它会为您提供一个工作模块。这是一种非常有用的方法，尤其是对于新手开发人员，他们可以从默认设置开始并在他们以后探索替代方案时对其进行更改。这比每次开始一个新项目时回答一堆难题要好得多。此外，Spring Boot 的官方网页上还有许多成熟的教程。这些将帮助您在初始阶段快速理解并实际实施所有主要类型的项目。

Spring Boot 还处于起步阶段，自然要经过多次蜕变才能完全稳定。用它来构建严肃的系统可能还为时过早，但它非常适合执行各种个人、培训和测试项目，以防你想消除大量无关的非生产性日常工作创造有用的功能。

就 Spring Boot 成长为一个严肃的开发工具的潜力而言，可接受的技术文档的存在看起来非常令人鼓舞。

现在让我们仔细看看使用 Spring Boot 的优缺点。

Spring Boot 应用程序的优点

Spring Boot 旨在使 Spring Framework 更易于使用。 Spring 提供了一个松散耦合的应用程序，这本身就是一个很棒的特性。然而，当涉及到几个松散耦合的块时，跟踪它们就变成了一项乏味且吃力不讨好的任务。这就是 Spring Boot 的用武之地，它通过以下功能帮助您保持简单：

• 快速轻松地开发基于 Spring 的应用程序；
• 无需部署war文件；
• 创建独立应用程序的能力；
• 帮助将 Tomcat、Jetty 或 Undertow 直接嵌入到应用程序中；
• 无需XML配置；
• 减少源代码数量；
• 额外的开箱即用功能；
• 轻松启动；
• 简单的设置和管理；
• 大型社区和许多培训计划，以促进熟悉期。

借助自动配置等功能，Spring Boot 为您省去了编码和不必要配置的麻烦。 Spring 框架不仅为您提供依赖注入或事务处理等功能，它还充当其他 Spring 框架的基础。最好的例子是 Spring Boot。 Spring Boot 使用 Spring Framework 作为其基础。它简化了 Spring 依赖项并直接从命令行运行应用程序。它也不需要外部应用程序容器。 Spring Boot 有助于在外部控制和自定义应用程序组件。

Spring Boot 的缺点

尽管 Spring Boot 有很多优点，但它仍然有一些缺点需要牢记：

• 缺乏控制。 Spring Boot 会创建大量未使用的依赖项，导致部署文件很大；
• 将遗留或现有 Spring 项目转换为 Spring Boot 应用程序的复杂且耗时的过程；
• 不适合大型项目。 尽管它非常适合使用微服务，但许多开发人员声称 Spring Boot 不适合构建单体应用程序。

原文:https://bambooagile.eu/insights/pros-and-cons-of-using-spring-boot/

本文：https://jiagoushi.pro/pros-and-cons-using-spring-boot

这篇冗长的文章讨论了Eclipse Foundation和Oracle之间关于命名空间和商标权的争议。

如果您在2017年错过了新闻，那么Oracle就会将Java EE规范捐赠给Eclipse基金会。这个决定在规范过程中进行了相当长时间的休眠，人们理所当然地怀疑Oracle对Java EE失去了战略兴趣。起初，Java EE和更广泛的Java社区很好地满足了捐赠规范的决定。如果没有Oracle放慢流程，那些参与Java EE的人可能会再次尝试关闭非标准化的API。直到今天，由于甲骨文和Eclipse基金会对捐赠的几个细节存在分歧，捐赠过程仍未完成。

在转换所有知识产权的同时，Oracle在规范的新家中使用其Java品牌时并不那么慷慨。当然，Java EE确实包含Oracle拥有的开源且受商标保护的平台的名称。这会在法律背景下产生问题：如果您授予第三方使用您的品牌名称，您将来有权限制它。更糟糕的是，当谈到有关您品牌的诉讼时，您可能会削弱您在法庭上的地位。随着甲骨文和谷歌多年来争论Java许可的历史，人们可以预见到品牌化将成为一个困难的讨论点。并且不假装对国际商标法有多少了解，有人告诉我更多参与者“使用它或失去它”对于理解这种分歧的一般格言是一个足够好的近似。因此，第一个结果是，规范从Java EE重命名为Jakarta EE，以避免利益冲突。

然而，新成立的雅加达EE社区的真正震惊还未到来。经过几个月的讨论捐赠手续，Eclipse基金会了解到它无法承担托管Java EE中定义的API的当前javax命名空间的所有权。相反，此命名空间现在计划为所有捐赠的API休眠。因此，任何将在Jakarta EE的规范过程中创建的新API都应该托管在新的命名空间中，以避免侵犯Oracle的商标。

在这一点上，澄清这意味着什么很重要。不禁止Jakarta EE和Eclipse Foundation使用javax命名空间或实现其API。也不会删除当前存在的API。但是，在新形成的Jakarta EE规范过程中创建或更新的任何API都需要存在于新的命名空间中，该命名空间最有可能模仿现有的命名空间，但使用jakarta作为其前缀而不是javax。例如，如果要将新方法添加到javax.servlet.Servlet接口，则下一版本的servlet规范需要发布名为jakarta.servlet.Servlet的新接口，而不是将此方法添加到现有API中。

我不是Java EE用户。我为什么要关心？

正如大多数人所知，Java平台正式分为两部分。第一部分是Java SE，其中所有API都在以java为前缀的包中定义。除此之外，Java EE还在javax命名空间中指定扩展API。这些API并不意味着特定的实现，而只是定义由不同Java EE兼容组件供应商实现的行为。

在这种情况下，Java EE是几个不依赖于彼此的API规范的总称。例如，Java消息传递规范（JMS）定义了用于与消息队列交互的API，而Java servlet规范定义了用于将调用分派给Web服务器的API。实际上，我所知道的Java EE应用程序运行时没有实现Java EE规范过程中定义的整个API。一些Java框架甚至专注于实现单一规范。例如，Jetty Web服务器仅实现Java servlet规范。因此，如果您通过Spring Boot使用Jetty，即使您没有直接与规范交互或认为自己是Java EE用户，您也正式成为Java EE的用户。

尽管存在这种形式上的区别，但即使您只编写了vanilla Java而没有包含任何外部依赖项，您也可能遇到过Java EE及其javax命名空间。这是因为选择的Java EE API与JVM的标准映像捆绑在一起。除了API之外，JVM还提供了此API的默认实现，以便用户无需任何额外工作即可轻松解决常见任务。例如，JAXP是一个Java EE规范，它定义了一个用于在Java中处理XML的API。由于XML处理是一项常见任务，特别是在面向企业的Java平台上，因此将其包含在内是一个合理的选择。对于JAXP，它假定的常见用法在今天仍然是事实，但其他JVM捆绑的Java EE规范并没有同样好的老化。例如，SOAP消息传递不再是大多数Java开发人员的首选，因此JVM捆绑的JAX-WS实现对于大多数用户来说已经变得非常重要。为了减少JVM的占用空间，并且在Java 9中引入了Java模块系统，一些Java EE API被移至已弃用的模块，这些模块计划在将来的版本中删除。当然，这并不意味着模块的API本身已被弃用。 JAX-WS仍然活跃并被许多人积极使用。但是由于这个模块被弃用，JAX-WS需要被那些想要在未来的Java版本中继续使用它的人添加为显式依赖。

在我们在虚拟化硬件上运行微服务的时代，减少JVM占用空间已成为演进JVM的明显目标。但是从基础JVM映像中删除Java EE API还有另一个优点。通过要求用户包含对Java EE API的显式依赖，升级Java运行时和Java EE不再捆绑在一起。在Java 8之前，管理这种版本的相互依赖性一直很乏味。如果您不控制要部署应用程序的JVM的确切版本，则尤其如此。在Java 8之前，JVM只允许您通过将JAR文件放入JVM的扩展文件夹来覆盖隐式Java EE依赖项。但是，当您与其他也会受到影响的Java进程共享JVM安装时，这当然是有问题的。此外，您仍然需要对正在使用的JVM安装进行一些控制。为了解决这个问题，默认情况下，Java模块系统不再解析已弃用的Java EE模块，这样可以在JVM中包含显式版本，尽管可以继续按需捆绑，同时还提供了一种激活旧版兼容性的简单方法。

为了使事情变得更加复杂，一小部分Java EE API以不允许简单分离的方式发展为Java SE。例如，JDBC规范分为“客户端”和“服务器端”需求，前者正式属于Java SE，后者则是Java EE的一部分。这种区别来自最初的Java哲学，其中人们将Java SE用于面向用户的桌面应用程序，而Java EE用于多个并发用户使用的服务器应用程序。本着这种精神，JDBC Connection接口例如在java.sql包中定义。毕竟，桌面用户当然可能想要连接到数据库。另一方面，JDBC DataSource接口在javax.sql包中定义，因为连接池仅被视为多线程服务器应用程序的要求。从今天的角度来看，这种分离当然不再有意义，但命名空间和形式上的区别在今天仍然存在。

当然，让JDBC API在由OpenJDK项目管理的Java SE和现在由Eclipse Foundation管理的Jakarta EE中单独发展是没有意义的。因此，并非Java EE规范的所有部分都捐赠给Eclipse，因此将为JDBC API保留javax.sql命名空间，该API现在被认为是仅Java SE的一部分。此类API保留的其他示例是JMX API，它严重依赖于本机JVM支持。当然，所有其他始终被认为是Java SE的一部分的API，例如最终在Java扩展名称空间中的Swing API，仍将保留在其原始包中。

那么向后兼容性怎么样？

需要记住的重要一点是，现在或将来，现有的javax API都不会消失。就个人而言，我还希望现在雅加达EE的一部分规范能够在未来许多年内支持javax命名空间。事实上，处理多个名称空间对于大多数Java EE实现来说并不是什么新鲜事，但它始终是一个需要处理的重要主题。例如，Hibernate库在逐渐用JPA规范定义的注释替换自己的注释时已经成功完成了类似的迁移。在另一个示例中，Spring框架支持与其本机注释并行的Java EE CDI规范。这样做，例如，可以通过使用javax.inject.Inject批注或Spring的本机Autowired批注来请求bean注入。一旦Inject注释转移到jakarta包，我就会期望Spring框架同时支持Java EE和Jakarta EE命名空间，因为我也期望它来自Java企业API的其他实现者。

由于Jakarta EE是Java EE的继承者，我不希望这种支持的实现或维护成本过高，因为应用服务器供应商可以简单地实现委托给现在过时的Java EE API的Jakarta EE包装器类。例如，通过定义类似于以下内容的包装类，可以在内部将Java EE servlet视为Jakarta EE servlet：

public class LegacyServlet implements jakarta.servlet.Servlet {

  private final javax.servlet.Servlet delegate;

  public LegacyServlet(javax.servlet.Servlet delegate) {

    this.delegate = delegate;

  }

  @Override

  public void service(jakarta.servlet.ServletRequest req, jakarta.servlet.ServletResponse resp) {

 delegate.service(new LegacyServletRequest(req), new LegacyServletResponse(resp));

  }

}

如果Jakarta EE以（逻辑）向后兼容当前规范和API为目标，这应该相当简单。如果遵循这一原则，这也将要求API的用户仅更新到Jakarta命名空间，以防他们想要使用已经需要代码更改的新功能。因此，我希望更改的命名空间不会过多地影响未来的Jakarta EE用户，但主要是那些实现其API的人的关注。回顾过去对Java平台的其他更基本的变化，例如，引入Java模块系统时也是如此，这主要涉及库和框架开发人员，但很少是Java的最终用户。

当然，对两个命名空间的支持永远不会是通用的，特别是从长远来看，因此Java EE API的用户最终需要对转换作出反应。鉴于规范保留了其API的二进制兼容性并排除了名称空间前缀的变化，我相信移植软件应该易于克服，甚至应该是可自动化的。任何Java类都在每个类文件的常量池中引用其导入的类型。使用新的jakarta前缀修补工件的所有常量池中的所有相关类型引用的工具将是微不足道的。这样做，Java EE的旧用户可以避免在被动维护下为其应用程序更改源代码，并且仅在编译后应用此类更改，甚至在部署期间修补工件。

 

什么驱动Oracle？

我当然是一名软件顾问，而不是国际商标管辖权的专家。我对甲骨文的决策过程也没有任何见解。因此，请将这最后一节作为有根据的推测与我的个人意见相混合而不是事实摘要。

Java社区中的一些声音目前正在指责Oracle通过限制javax命名空间的使用来反对Java及其用户的兴趣。 Eclipse基金会中也有激烈的争论，以至于有人建议以这种方式捐赠Java EE可能会被拒绝，因为它与组织的目标和价值观不相容。

鉴于这种变化确实给Java用户带来了重大的工作，当然可以很快得出这个观点。但是，我无法想象甲骨文会轻易做出这个决定。 Oracle已经并且一直在Java平台上进行大量投资 -  Java很少像现在这样活跃 - 但它也改变了它的战略方向。对我而言，Oracle在进行这些投资时“不关心”Java社区的想法根本不合适。

那么我认为如何推动这一决定呢？对我而言，限制与Java EE几乎没有关系，而是关于Oracle保护其对Java SE的兴趣。在一天结束时，甲骨文正在投资Java以获取利润。通过允许使用其商标，甲骨文将放弃对其品牌的控制权，从而使这一目标陷入危险境地。当然，Oracle依靠Java来生产自己的产品，并因此保留了它。但与此同时，该公司正在尝试创建一个战略模型，证明为数百名从事Java工作的全职和高素质员工提供资金。

甲骨文显然正在推动销售云解决方案，鉴于该公司目前在运营时和数据库方面的主导地位，除了雄厚的资金外，我相信他们在这一领域获得重要市场份额的机会要好于许多人的预期。 Oracle的另一个迹象是它对Graal VM及其编译器的投资，它还在资源受限的环境（如容器）中为Java语言提供了更广泛的应用范围。

但在投资某些领域的同时，甲骨文肯定也在研究削减成本的方法，例如终止不再具有战略利益或盈利能力不足的企业。虽然让用户（包括我自己）感到悲伤，但像Java飞行记录器这样的成功项目团队被解雇了，但考虑到绝大多数Java开发人员都没有要求这样的工具，这是有道理的。我认为Java EE不符合Oracle的平台计划或成本，并遭遇了类似的命运。.

有鉴于此，甲骨文可能考虑在放弃规范与捐赠给其他人维护之间进行权衡。虽然捐赠Java EE的选择似乎没有成本，但甲骨文当然会通过捐赠来承担风险。通过允许竞争组织继续他们在Java EE中的努力，这些努力也可能增强他们在Java SE领域与Oracle竞争的能力。对于红帽和IBM来说尤其如此 - 它们也在云解决方案市场上竞争。通过保护其品牌权，Oracle的目标只是降低Java EE被竞争对手武器化以在未来争夺Java SE市场份额的风险。公平地说，Oracle为Eclipse基金会提供了一种继续使用javax命名空间的方法。但是，这需要基础来限制自己将其产品与JVM的Java SE认证实现捆绑在一起，而不是例如它自己的IBM捐赠的OpenJ9。这样做，甲骨文将保留对其品牌的充分控制，但与此同时，签署如此广泛的协议不符合基金会的利益是非常可以理解的。它本来就没有意义，从这个角度来看，人们甚至认为Eclipse首先是接受Java EE捐赠的错误选择。

接下来是什么？

在开源社区，我们经常讨论我们的工作资金不足。虽然缺乏盈利能力对于个人开发者来说是个问题，但对于大型企业来说当然也是一个问题，无论是甲骨文还是参与当前讨论的任何其他公司。在我看来，通过Oracle捐赠Java EE的知识产权，Java社区已经交付了规范中最重要的部分，我们应该专注于我们拥有的东西，而不是被附加的字符串过度分散注意力。就个人而言，如果Oracle对Java品牌失去兴趣而不是采取立场，我会更担心Java的未来。

至于Jakarta EE，我不认为即将发生的命名空间迁移是规范面临的最大问题。许多开发人员甚至在最近的停滞期之前就对Java EE的尘埃感到沮丧。在我看来，问题是这个过程的一部分。实际上，Java EE规范通常源自领先框架的实现。如果另一个框架想要重新发明如何通过更好的API解决同样的问题，它需要面对不遵守标准的不断批评。这一切尽管这个标准通常只是以前最佳实践的快照。出于这个原因，我希望雅加达EE能够专注于它的发展，而不是过分坚持它的过去。通过提供最先进的API的引人注目的产品，我不会太担心调整我的代码，如果它让我免于实现最小化jakarta.servlet.Servlet API的迭代。

原文：https://dzone.com/articles/jakarta-ee-without-javax-the-world-wont-end-this-time-either

本文：http://pub.intelligentx.net/jakarta-ee-without-javax-world-wont-end-time-either

讨论：请加入知识星球或者小红圈【首席架构师圈】

进入 2022 年，Java 仍然是世界上第三大最受欢迎的编程语言。它包含一个庞大的生态系统和全球超过 900 万的 Java 开发人员。 Java有很多优点；最重要的是，它是一种独立于平台的语言（一次编写，随处运行），遵循面向对象的编程范式，易于理解、编写和调试。

由于该语言的成熟和流行，您不必从头开始编写 Java 程序。有许多优秀的 Java 框架可以编写在 Java 虚拟机上运行的 Web 和移动应用程序、微服务和 REST API。

在本深入指南中，我们将研究 17 个主要用于 Web 开发的流行 Java 框架。

什么是 Java 框架？

Java 框架是为使构建 Java 应用程序更容易和更快而创建的软件库。它们由预先编写的代码、类、模板、组件和其他结构组成，您可以将它们用作 Java 应用程序的基础。

最好的 Java 框架经过充分测试，并强制使用编码最佳实践。它们让您专注于应用程序的业务逻辑，而不是编写基本功能，例如建立数据库连接或处理异常。

但是，并非所有 Java 框架都具有相同的目的，因此在它们之间进行选择不仅仅是偏好问题。有些允许您创建全栈 Java Web 应用程序，而另一些则专注于前端或后端，还有一些框架用于处理数据库操作等额外任务。在某些情况下，您可能希望同时使用多个框架，因此了解这些 Java 框架如何相互比较和集成非常重要。

前 17 个 Java 框架

我们选择按字母顺序列出我们排名前 17 的 Java 框架，而不是按“质量”排名，因为它们的结构和用途不同。

我们包含了允许您创建视图层的 Java 前端框架、允许您与数据库交互的 ORM 和持久性框架、有助于创建微服务和 REST API 的 Java 后端框架、构建在其他 Java 框架之上的 Java 框架，和更多。

本文重点介绍 Web 开发，因此需要注意的是，这并不是一个详尽的列表，还有其他类型的 Java 框架，例如日志框架。

让我们从 B for Blade 开始。

Blade：占用空间最小的简单应用程序框架

Blade：占用空间最小的简单应用程序框架
Blade 是一个轻量级的高性能 Java 框架，它允许您以高效的方式构建快速的 Web 应用程序。创建者的目标是让用户在一天内了解整个框架。为了实现这一点，Blade 专注于简单和优雅。

Blade 框架遵循 MVC（模型-视图-控制器）软件设计模式。它具有易于理解的设计，不依赖任何第三方库或引入太多层。 Blade基于Java 8，框架内置Netty Web服务器和模板引擎。它占地面积小；源代码总共不到 500kb。

使用 Blade，您可以访问 RESTful 样式的路由接口，并且可以将您的应用程序部署为基本的 Maven 或 Gradle 项目。 Blade 也有内置的安全功能；例如，它带有 CSRF（Cross-Site Request Forgery）和 XSS（Cross-Site Scripting）防御。它是一个多功能框架，支持插件扩展和 webjar 资源。

优点： - 无依赖关系 - 易于部署 - 小型轻量级框架
- 嵌入式网络服务器 - 模板引擎支持 - 平坦的学习曲线

缺点： - 教程和示例项目不多 - 现在开发活动不太活跃

Dropwizard：生产就绪的 RESTful Web 服务

Dropwizard：生产就绪的 RESTful Web 服务
Dropwizard 是一个高性能但简单的 Java 框架，用于快速开发 RESTful Web 服务。它特别适合创建 Java 微服务。

Dropwizard 框架汇集了几个完善的 Java 库，为您提供快速且无干扰的开发平台。它带有嵌入式 Jetty 服务器、Google Guava、Logback、Hibernate Validator、Joda Time 和许多其他流行的 Java 库。 Dropwizard 还包含可用于构建 RESTful Web 服务的 Jersey 和用于处理 JSON 的 Jackson。您可以将 Dropwizard 视为一个单独的生态系统，其中包含捆绑到单个包中的所有上述依赖项。

如果您选择 Dropwizard，则不必在辅助功能上花费太多时间，例如必须为配置、指标或日志记录编写代码。相反，您可以专注于应用程序的主要业务逻辑并实现最大生产力。这就是为什么 Dropwizard 通常被称为操作友好的 Java 框架的原因。

优点： - 易于设置和开始 - 轻量级 - 由成熟的 Java 库组成 - 良好的约定 - 可扩展 - 大量文档

缺点： - 你可能会觉得它有点太自以为是了

Grails：基于 Groovy 的 Web 应用程序框架

Grails 是一个使用 Groovy 编程语言的 Web 应用程序框架。 Groovy 是一种面向对象的 Java 平台语言，旨在提高开发人员的工作效率。它的语法与 Java 兼容，并编译为 JVM（Java 虚拟机）字节码。

尽管您必须在 Groovy 中编写代码，但 Grails 可以很好地与其他 Java 相关技术（例如 Java Development Kit、Java EE 容器、Hibernate 或 Spring）配合使用。在底层，Grails 构建在 Spring Boot 之上，以利用其生产力友好的特性，例如 Spring 的依赖注入。 Grails 最好的一点是，您可以用更少的代码实现相同的结果——这要归功于 Groovy 语言的强大功能。

Grails 遵循一些现代软件开发原则，例如约定优于配置、固执己见的 API 以强制执行最佳实践以及合理的默认值。它也对开发人员非常友好，因为它带有详细且易于阅读的文档、分步指南和广泛的插件库。您还可以构建自己的插件并利用 Grails 对 Eclipse、Sublime、Textmate、IntelliJ IDEA 和其他平台的 IDE 支持。

优点： - 建立在 Spring Boot 之上（见下文，作为 Spring 框架的一部分） - 与 Java 库和工具的无缝集成 - 约定优于配置（具有合理的默认值） - 异步功能 - 用于 React 和 Angular 的应用程序配置文件 - 高质量文档和大量的学习资料

缺点： - 你需要了解 Groovy 才能编写 Grails 应用程序

GWT：Google Web Toolkit：部署为 JavaScript 的客户端 Java 应用程序

GWT 或 Google Web Toolkit 是由 Google 创建的 Web 框架。您可以使用它为 Web 快速构建 Java 应用程序，因为它允许您编写客户端 Java 代码并将其部署为浏览器的 JavaScript。

GWT（读作“gwit”）是一个稳定且维护良好的 Java 框架。没有什么比它出现在 AdWords、AdSense、Blogger 和 Google Wallet 等多种 Google 产品中更能说明这一点了。 Google Web Toolkit 还有一个信息量很大的网站，其中包含教程、开发人员指南和入门应用程序。

使用 GWT，您无需成为 JavaScript 优化或响应式设计等前端技术专家即可构建基于浏览器的应用程序。 GWT 提供了许多高级功能，例如国际化、跨浏览器可移植性、UI 抽象、书签和历史管理。

优点： - 处理浏览器兼容性（包括移动浏览器） - 集成调试功能 - 代码优化功能 - 允许您对前端代码进行单元测试 - 平坦的学习曲线（适用于 Java 开发人员）

缺点： - 无法控制您的 JavaScript 或前端代码 - 生成非语义 HTML 代码

Hibernate：用于更好的数据库通信的对象关系映射框架

Hibernate：用于更好的数据库通信的对象关系映射框架
Hibernate 是一个稳定的对象-关系映射框架，它可以在 Java 编程语言和关系数据库管理系统 (RDBMS) 之间实现更好的通信。

当您使用 Java 等面向对象 (OO) 语言时，您会遇到一个称为 Object-Relational Impedance Mismatch（有时也称为 Paradigm Mismatch）的问题。 OO 语言和 RDBMS 处理数据的方式不同，这可能导致不匹配问题。 OO 语言将数据构造为对象的层次结构，而关系数据库则以表格格式表示数据。这些不匹配问题之一是当对象模型的类多于关系数据库中可用表的数量时。

Hibernate 为您提供了一个克服 Java 不匹配问题的框架。它旨在实现持久性，这意味着应用程序创建/使用的数据应该比生成它的过程更长。虽然 Hibernate 是为关系数据库构建的，但其较新版本也提供对 NoSQL 数据存储的支持。它还拥有出色的开发人员工具，例如映射编辑器、Hibernate 控制台和数据库逆向工程工具。

优点： - 面向对象的接口（不需要 SQL 接口） - 使任何类或数据结构都可以持久化 - 支持多种获取策略 - 自动版本控制和时间戳 - 可扩展性良好 - 高度可扩展和可配置

缺点： - 复杂查询的性能较低 - 学习曲线陡峭

Jakarta Server Faces (JSF)：基于组件的 UI 框架

Jakarta Server Faces (JSF)，以前称为 JavaServer Faces，由 Oracle 开发，作为为基于 Java 的 Web 应用程序构建用户界面的规范。它也是 Java Community Process (JCP) 倡议的官方标准。

Jakarta Server Faces 的第一个版本于 2004 年发布，因此它是一个稳定的框架。它遵循 MVC 软件设计模式，并具有基于组件的架构。使用 Jakarta Server Faces，您可以构建由可重用组件组成的用户界面，管理组件的状态，将它们连接到数据源，并将用户生成的事件绑定到服务器端的事件处理程序。

JSF 的默认模板系统是为项目显式创建的 Facelets。使用 Facelets，您可以使用 XML 而不是 Java 来处理视图。但是，您也可以使用 XUL（XML 用户界面语言）和纯 Java 等其他技术创建视图。使用 Jakarta Server Faces 创建的 Web 应用程序可以跨不同的 Jakarta (Java) EE 应用程序服务器移植。

优点： - 可靠性（由 Oracle 开发和维护的代码） - 建立在 Servlet API 之上 - 跨浏览器兼容性 - 自动状态管理 - 支持优雅降级和多种输出格式 - 相对较低的学习曲线（适用于 Java 开发人员）

缺点： - 难以调试 - 教程或学习材料不多

JHipster：使用 Spring Boot 和 Angular/React 的 Web 应用程序和微服务

JHipster 将 Spring Boot 和流行的前端框架（Vue、Angular、React 等）结合在一个方便的 Web 应用程序生成器中。它被 Adob​​e、西门子、博世、HBO 和谷歌等领先品牌使用。使用 JHipster，您可以快速创建基于 Java 的现代 Web 应用程序和微服务。

Spring Boot 允许您创建以最少配置工作的生产级基于 Spring 的应用程序（请参阅下面有关 Spring 框架的更多信息）。 JHipster 将其与客户端的 Angular、React、Vue 和 Bootstrap 相结合，为您提供全栈架构。如果您想了解 JHipster 应用程序在现实生活中的样子，请查看由 JHipster 团队创建的 Angular、React 和 Vue 示例应用程序。

JHipster 允许您在两种架构风格之间进行选择。您可以选择将前端和后端组合成一个应用程序的单体架构。或者，您可以使用分离前端和后端的微服务架构。 JHipster 还集成了多种工具，并为客户端和服务器端编码、捆绑和不同的 DevOps 任务提供了大量选项。

优点： - 显着加快开发速度 - 支持许多前端框架和技术 - 支持移动应用程序开发（Ionic 和 React Native） - 构建在 Spring Boot 之上（因此您可以使用依赖注入和 Spring Boot 的其他功能） - 多个部署选项 - 活跃的社区和包含示例项目的大量文档

缺点： - 大量自动生成的代码可能会让初学者感到困惑

MyBatis：用于更轻松 SQL 管理的持久性框架

MyBatis 是一个用于 Java 应用程序的持久性框架，它使使用关系 (SQL) 数据库变得更加容易和快捷。该框架充当应用程序和数据库之间的中间件，并解决了源自其不同架构的问题。

您可以将 MyBatis 视为应用程序的 Java 代码和底层 SQL 数据库之间的抽象层。默认情况下，您需要使用 JDBC（Java 数据库连接）API 从您的 Java 代码访问数据源，例如关系数据库或电子表格。 MyBatis 简化了这个过程，让你用更少的代码与关系数据库进行交互。例如，您可以只用一行代码执行 SQL 语句。

MyBatis 类似于 Hibernate 框架，都旨在改善应用层和数据库之间的通信。然而，MyBatis 并不像 Hibernate 那样将 Java 对象映射到数据库表，而是将 Java 方法链接到 SQL 语句。因此，当您使用 MyBatis 框架时，SQL 是可见的，并且您仍然可以控制 SQL 的执行（另一方面，您需要自己编写 SQL 语句并设置映射） .

优点： - 易于使用和学习（适用于 Java 开发人员） - 轻量级 - 快速开发 - 与 Spring 框架兼容 - 简单获取的出色解决方案 - 可移植性 - 数据库独立接口 - 能够构建动态 SQL 查询

缺点： - 高度依赖 SQL - 难以调试 - 不如 Hibernate 灵活

Play：用于高度可扩展的 Java 应用程序的响应式 Web 和移动框架

Play 框架使构建用于桌面和移动设备的轻量级和网络友好的 Java 和 Scala 应用程序成为可能。 Play 是一个非常流行的框架，被 LinkedIn、三星、沃尔玛、卫报、Verizon 等公司使用。

Play 经常被比作其他编程语言的强大 Web 框架，例如 Ruby on Rails 的 Ruby 或 Django 的 Python。与大多数 Java 框架不同，它不依赖于 Jakarta EE 标准。它旨在消除传统 Java Web 开发的不便，例如开发周期慢和配置过多。因此它更类似于脚本语言（PHP、Python、Ruby 等）的 Web 框架。

在底层，Play 构建在 Akka 工具包之上，该工具包简化了在 Java 虚拟机上创建并发和分布式应用程序。因此，Play 使用了完全异步的模型，可以带来更好的可扩展性，特别是因为它还遵循无状态原则。

Play 框架通过热代码重新加载、约定优于配置和浏览器中的错误消息等功能将开发人员的生产力放在首位。此外，它是一个响应式系统，遵循现代系统架构（响应式、弹性、弹性和消息驱动），以实现更灵活和容错的结果。

优点： - 轻量级 - 高可扩展性 - 异步核心 - 支持 Web 技术（REST、JSON、Web 套接字等） - 强大的开发人员工具 - 许多云部署选项 - 广泛的文档和活跃的社区

缺点：

向后兼容性问题（Play 1.x 与 Play 2.x 不兼容，而且 Play 2.x 的次要版本之间可能存在较小的兼容性问题）

PrimeFaces：Jakarta EE 和 Jakarta Server Faces 的 UI 框架

PrimeFaces 是一个流行的 Web 框架，用于为 Jakarta EE 和 Jakarta Server Faces（见上文）应用程序创建轻量级用户界面。许多财富 500 强公司、政府实体和教育机构都在使用它。

PrimeFaces 库是真正轻量级的。它被打包为单个 JAR 文件，需要零配置，并且没有任何依赖项。它允许您使用一组丰富的组件、内置的皮肤框架以及预先设计的主题和布局为 Java 应用程序创建用户界面。由于 PrimeFaces 建立在 Jakarta Server Faces 之上，因此它继承了其特性，例如快速应用程序开发。您还可以将框架添加到任何 Java 项目中。

在 PrimeFaces 网站上，您可以找到所有 PrimeFaces 组件、模板和主题的精彩展示。这些组件带有相关的代码片段，您可以快速复制/粘贴到您的应用程序中 - 或在必要时对其进行调整。例如，这是一个水平的巨型菜单，可让您一起显示根项目的子菜单。

PrimeFaces 还有一个主题设计器，它是一个基于 Sass 的主题引擎，具有 500 多个变量、一个示例主题和字体图标。如果您不想自己构建主题，您还可以下载社区主题或从 PrimeFaces 主题库购买高级主题。

优点： - 易于上手 - 稳定性（建立在 JSF 之上） - 支持移动功能（例如触摸优化组件） - 流行前端库的现成 UI 组件（例如，用于 Angular 的 PrimeNG、用于 React 的 PrimeReact 和 PrimeVue Vue）——预先设计的前端布局和模板（但是，不是免费的——价格从 39 美元起）
- 活跃的社区

缺点： - 掌握它需要时间（您需要了解 Jakarta Server Faces 才能正确使用 PrimeFaces）

Spark 框架：Web 应用程序和 REST API 的微框架

Spark 框架是用于 Java 和 Kotlin 编程语言的微框架和特定领域的语言。 Kotlin 在 Java 虚拟机上运行，​​并且与 Java 100% 可互操作。 Spark 可帮助您开发基于 Java 的 Web 应用程序、微服务和 REST API。

微框架首先出现在 Ruby 和 PHP 等脚本语言中，并由于其专注于开发速度和简单性而迅速获得关注。 Spark 的灵感来自 Ruby 的 Sinatra Web 应用程序框架，并于 2011 年首次发布。它不是 MVC 框架，但可以让您按照自己的方式构建应用程序。与大多数微框架一样，它的代码库很小，需要最少的配置，并且不需要您编写太多的样板代码。

您可以在几分钟内启动并运行 Spark 框架。默认情况下，它在嵌入到框架中的 Jetty Web 服务器上运行。但是，您也可以将它与其他 Java Web 服务器一起使用。根据 Spark 自己的调查，超过 50% 的用户使用该框架创建 REST API，这是其最受欢迎的用例。 Spark 还为每天为超过 10,000 名用户提供服务的高流量 Web 应用程序提供支持。

请注意，Spark 框架与 Apache Spark 不同，后者是用于大数据处理的分析引擎。

优点： - 轻量级 - 允许快速开发 - 需要很少的样板代码 - 声明性和表达性语法 - 无主见（您可以根据需要构建应用程序）

缺点： - 这些天开发不太活跃 - 教程和学习材料不多

Spring Framework：企业级Java应用框架

Spring 框架可能是最知名和最流行的 Java 框架，拥有庞大的生态系统和活跃的社区。它允许您构建企业级 Java 应用程序、Web 服务和微服务。

Spring 框架最初是一个依赖注入工具，但多年来它已经发展成为一个完整的应用程序框架。它为您提供了一个包罗万象的编程和配置模型，支持建立数据库连接和处理异常等通用任务。除了 Java，您还可以将框架与运行在 Java 虚拟机上的 Kotlin 和 Groovy 一起使用。

Spring 框架利用控制反转 (IoC) 软件设计原则，框架根据该原则控制自定义编写的代码（与传统编程相反，传统编程中自定义代码调用处理通用任务的其他库）。因此，您可以为 Spring 应用程序创建松散耦合的模块。

虽然 Spring 框架非常适合构建企业级 Java 应用程序，但它确实有一个陡峭的学习曲线。这是因为它是一个广泛的框架，旨在为可能出现企业级应用程序的每项任务提供解决方案，并且还支持许多不同的平台。因此，配置、设置、构建和部署过程都需要您可能不想处理的多个步骤，尤其是在您处理较小的项目时。 Spring Boot（Spring 框架的一个扩展）是解决这个问题的一个解决方案，因为它允许您更快地设置您的 Spring 应用程序，并且配置少得多。

优点： - 非常流行且非常稳定的框架 - 灵活的配置 - 松散耦合（由于依赖注入） - 易于测试应用程序（由于依赖注入） - 使用 POJO（普通旧 Java 对象） - 广泛的文档 - 活跃的社区

缺点： - 复杂性（高学习曲线） - 需要编写大量样板代码（除非您使用 Spring Boot）

Struts：用于企业级 Java 应用程序的 MVC 框架

Struts 是一个较旧的框架，仍然被许多开发人员使用。它是由 Apache Software Foundation 维护和开发的全功能 Java Web 应用程序框架。它是一个拥有庞大社区的可靠平台，通常与 Spring 框架相比。 Struts 允许您创建随着时间的推移易于维护的企业级 Java 应用程序。

它遵循 MVC 软件设计模式，并具有基于插件的架构。插件可以扩展框架以适应不同的项目需求。 Struts 插件是基本的 JAR 包，因此它们是可移植的，您也可以将它们添加到应用程序的类路径中。一些插件与框架捆绑在一起（JSON 插件、REST 插件、配置浏览器插件等），而您可以从第三方来源添加其他插件。

您可以将 Struts 与其他 Java 框架集成以执行未内置于平台中的任务。例如，您可以使用 Spring 插件进行依赖注入或使用 Hibernate 插件进行对象关系映射。 Struts 还允许您使用不同的客户端技术（例如 Jakarta Server Pages）来构建应用程序的前端。

但是，如果您想创建可以在前端渲染的服务器端组件，Struts 可能不是最好的选择。相反，您应该研究具有不同架构的框架，例如 Tapestry 或 Wicket（见下文）。

优点： - 稳定和成熟的框架 - 约定优于配置 - 可扩展（通过插件） - 易于与其他 Java 框架和工具集成 - 支持 Web 技术（REST、AJAX、JSON）

缺点： - 不提供任何安全机制（请参阅您需要自己申请的安全提示）

Tapestry：面向组件的高度可扩展应用程序框架

Tapestry 是一个基于组件的 Java 框架，您可以使用它创建可扩展的 Web 应用程序。它对可重用组件的关注使其在架构上类似于 Jakarta Server Faces 和 Wicket 框架。与 Struts 一样，Tapestry 也是 Apache 软件基金会的一个项目。

您可以将 Tapestry 页面和组件编写为普通的旧 Java 对象 (POJO)，因此您可以从框架访问整个 Java 生态系统。除了 Java，Tapestry 还支持 Groovy 和 Scala，并与 Hibernate 和 Spring 等其他 Java 框架集成。 Tapestry 的构建考虑了性能；因此，它为您提供了诸如实时类重新加载、异常报告、Ajax 支持以及内置组件和模板等功能。

Tapestry 也是一个对开发人员友好的框架。它具有促进测试驱动开发 (TDD) 的内置实用程序，并支持 Selenium 测试框架。 Tapestry 在单个服务器和服务器集群上都可以很好地扩展。使用 Tapestry 构建的应用程序可以在浏览器中快速运行，因为它遵循客户端缓存、支持并发线程、JavaScript 聚合和压缩、集成 GZip 内容压缩等最佳实践。

优点： - 可扩展 - 易于测试 - 约定优于配置 - 组件是纯 Java 对象 - 带有预制组件 - 出色的异常报告

缺点： - 很难找到教程和学习材料

Vaadin：专注于 UX、可访问性和移动的 Web 应用程序框架

Vaadin 为简化的 Java 开发提供了一个平台。它允许您构建专注于性能、用户体验和可访问性的可定制组件的 Web 应用程序。

Vaadin 10+ 以全新的方式处理 Web 应用程序开发：它让开发人员可以直接从 Java 虚拟机访问 DOM（文档对象模型）。在新版本中，Vaadin 团队将以前的单一框架分成了两部分。它有一个名为 Vaadin Flow 的轻量级 Java 框架，用于处理路由和服务器-客户端通信，以及一组在用户浏览器中运行的 UI 组件。

这些组件是移动优先的，并遵循最新的网络和可访问性标准；它们是基于 Web Components 标准构建的。您可以将 Vaadin 组件与任何前端框架（例如 React、Angular 或 Vue）一起使用。创建者还推荐它们作为渐进式 Web 应用程序的构建块。您可以基于 Vaadin 组件构建自己的主题，也可以使用 Vaadin 的两个预制主题：Lumo（默认）和 Material。

Vaadin Flow 提供高级 Java API 来管理应用程序的所有技术方面，从服务器-客户端自动通信到 WebSocket 再到数据绑定。由于 Flow 在 JVM 上运行，您可以访问整个 Java 生态系统，例如，您可以使用 Spring Boot 运行您的应用程序。 Flow 还允许您使用 Kotlin 或 Scala 编写应用程序。

优点： - 使用独特的编程模型 - 遵循 Web 标准 - 适合移动设备的组件 - 可扩展（参见 Vaadin 目录） - 与 Spring 框架无缝集成 - Java 应用程序的预制主题（免费提供）

缺点： - Vaadin 是一家营利性公司，因此您需要为专业组件、工具和支持付费（参见定价）。

Vert.x：用于 Java 虚拟机的多语言事件驱动应用程序框架

Vert.x 是一个运行在 Java 虚拟机上的多语言框架。它允许您使用 Java、JavaScript、Groovy、Ruby、Scala 和 Kotlin 等编程语言编写应用程序。它的事件驱动架构使应用程序即使在硬件资源最少的情况下也能很好地扩展。

Vert.x 由 Eclipse 基金会开发和维护，其最著名的项目是 Eclipse IDE。 Vert.x 中的“x”指的是它的多语言特性，这意味着您可以用几种不同的语言编写有效的代码。它为每种受支持的编程语言提供惯用的 API。

由于 Vert.x 是一个事件驱动的非阻塞框架，它可以只使用最少数量的线程来处理大量并发。 Vert.x 也非常轻量级，核心框架仅重约 650 KB。它具有模块化架构，允许您仅使用所需的模块，以便您的应用程序尽可能保持流畅。如果您想构建轻量级、高度可扩展的微服务，Vert.x 是一个理想的选择。

优点： - 加载速度快 - 模块化架构 - 可扩展 - 不拘一格（您可以根据需要构建应用程序） - 易于使用的应用程序生成器 - 大量文档

缺点： - 高学习曲线（更多的是高级工具包而不是框架，因此您需要自己做出很多决定）

Wicket：面向纯粹主义者的基于组件的 Web 应用程序框架

Wicket 是一个基于组件的 Web 应用程序框架，类似于 Jakarta Server Faces 和 Tapestry。它允许您使用纯 Java 和 HTML 代码编写优雅、用户友好的应用程序。该框架由 Apache Software Foundation 维护，类似于 Struts 和 Tapestry。

由于 Wicket 是一个基于组件的框架，因此应用程序由可重用的页面和组件组成，例如图像、按钮、链接、表单等。它使用 POJO 数据模型，因此 Wicket 组件是普通的 Java 对象。组件被捆绑为可重用的包，因此您可以向它们添加自定义 CSS 和 JavaScript。

Wicket 通过为超过 25 种语言提供开箱即用的支持，让您的应用程序、页面和组件国际化。内置的 Ajax 功能允许您实时更新页面的某些部分，而无需编写任何 JavaScript 代码。 Wicket 也关注安全的 URL 处理。组件路径是会话相关的，并且 URL 不会泄露任何敏感信息。如果您想了解 Wicket 在现实生活中的工作原理，请查看使用 Apache Wicket 构建的博客，您可以在其中看到一些不错的示例。

优点： - 分离标记和逻辑 - 不需要 JavaScript 或 XML 配置文件 - 与标准 HTML 无缝集成 - 简单的状态管理（组件是 Java 对象维护它们的状态） - 您可以对前端代码进行单元测试

缺点： - 相对较小的社区；教程或学习资料不多

下一步

这是我们对 Java 框架比较的总结。由于这些框架中的每一个都有不同的用途，因此在为您的特定 Java 项目选择一个或多个框架之前，了解它们的优缺点和功能至关重要。

要选择正确的框架，您需要考虑您的目标（您想要构建什么？）、您的预算和团队的知识，以及其他因素。

 

Java开发工具包（JDK）18定于2022年3月22日发布。标准Java的新版本将有九个新特性，特性集已于12月9日冻结。

自1月20日起，该版本进入了第二个降级阶段，此前上个月开始了第一个降级阶段。标准Java的升级每六个月发布一次，最新的JDK17将于9月份发布。

OpenJDK页面列出了以下正式针对JDK 18的功能：服务提供商接口、简单web服务器、向量API、代码片段、核心反射的重新实现、UTF-8字符集、外部函数和内存API的第二个孵化器、switch语句模式匹配的第二个预览、，以及最后一次添加的对Finalization 的反对。

JDK18的候选版本将于2月10日和2月24日发布。虽然JDK 17是一个长期支持（LTS）版本，将获得Oracle至少八年的支持，但JDK 18将是一个短期功能版本，支持期为六个月。JDK18的早期访问版本可以在java上找到，用于Linux、Windows和MacOS。网

JDK 18提案的具体内容包括：

• finalization在将来的版本中被删除(Deprecate finalization for removal in a future release)。Finalizer 的缺陷会在安全性、性能、可靠性和可维护性方面造成重大的现实问题。它还有一个困难的编程模型。默认情况下，目前已启用Finalization ，但可以禁用以便于早期测试。默认情况下，它将在功能版本中禁用，并在以后的版本中完全删除。该提案要求使用命令行选项来禁用标准JavaAPI中所有Finalizer 和Finalization 方法的Finalization 和弃用。该提案的目标包括帮助开发人员理解定稿的危险，为最终删除定稿做好准备，并提供简单的工具来帮助检测对定稿的依赖。在Java1.0中引入的Finalization 旨在帮助避免资源泄漏。类可以声明Finalizer （受保护的void finalize（）方法），其主体释放任何底层资源。垃圾收集器将在回收对象内存之前，计划调用不可访问对象的Finalizer ；反过来，finalize方法可以执行诸如调用对象的close之类的操作。这似乎是防止资源泄漏的有效安全网，但存在缺陷，包括不可预测的延迟，从对象变得不可访问到调用其Finalizer 的时间间隔很长；不受约束的行为，Finalizer 代码可以执行任何操作，包括恢复对象并使其再次可访问；Finalizer 始终处于启用状态，没有明确的注册机制；Finalizer 可以在未指定的线程上以任意顺序运行。考虑到Finalization 的问题，建议开发人员使用其他技术来避免资源泄漏，即尝试使用resources语句和Cleaner。（有关详细信息，请参阅JDK增强方案421。）
• 对于Internet地址解析SPI，建议为主机和名称地址解析定义一个SPI，以便Inet.Address 可以使用平台内置解析器以外的解析器。这项工作的动机包括更好地支持ProjectLowe、Java中的并发性和新编程模型，以及集成新的网络协议、定制和启用测试。该提案不涉及为JDK开发替代解析器。
• switch模式匹配的第二个预览，其中Java语言将通过switch表达式和语句的模式匹配以及模式语言的扩展得到增强。这是在JDK 17中预览的。通过将模式匹配扩展到switch，可以针对多个模式测试表达式，每个模式都有一个特定的操作，因此可以简洁而安全地表达复杂的面向数据的查询。
• 使用方法句柄重新实现核心反射将重新实现lang.reflect。方法、构造函数和位于java之上的字段。调用方法句柄。将方法句柄用作反射的底层机制将降低java和java的维护和开发成本。lang.reflect和java。lang.invoke API。
• 使用简单的web服务器方案，将提供一个命令行工具来启动一个只提供静态文件的最小web服务器。没有CGI或类似servlet的功能可用。该工具将有助于原型设计、特殊编码和测试，特别是在教育环境中。该计划的目标包括提供一个开箱即用的静态HTTP文件服务器，具有简单的设置和最少的功能，减少开发人员的激活能量，使JDK更容易接近，并通过命令行提供一个默认实现，以及一个用于编程创建和定制的小API。提供功能丰富的或商业级服务器不是本提案的目标。
• 外部函数和内存API的第二个孵化，其中引入了一个API，通过该API，Java程序可以在Java运行时之外与代码和数据进行互操作。通过调用外部函数（JVM外部的代码）和安全访问外部内存（JVM不管理的内存），API允许Java程序调用本机库并处理本机数据，而不会出现JNI（Java本机接口）的脆弱性和危险性。其目的是用一个优秀的纯Java开发模型取代JNI。这个API是在JDK 17中培育出来的。对于JDK18，将根据反馈进行改进，例如支持更多载体，如内存访问变量句柄中的布尔和MemoryAddress，以及在内存段之间复制Java数组的新API。
• 向量API将在JDK 18中第三次孵化，之前在JDK 16和JDK 17中孵化过。该方案将在运行时编译的向量计算表示为支持的CPU架构上的最佳向量指令，实现优于等效标量计算的性能。向量操作表示一定程度的并行化，使更多的工作可以在单个CPU周期内完成，从而显著提高性能。平台无关矢量API旨在提供一种用Java编写复杂算法的方法，使用现有的热点自动矢量器，但使用一种用户模型，使矢量化更可预测。JDK18还将增加对ARM标量向量扩展平台的支持，并改进向量操作的性能，这些向量操作在支持硬件掩蔽的体系结构上接受掩蔽。
• 将UTF-8指定为标准JavaAPI的默认字符集。UTF-8是一种用于电子通信的可变宽度字符编码，被认为是web的标准字符集。字符集是一种字符编码，能够对web上的所有字符进行编码。通过此更改，依赖于默认字符集的API将在所有实现、操作系统、区域设置和配置中保持一致。该提案并不打算定义新的Java标准或JDK特定的API。该提案的支持者预计，Java选择UTF-8不会对许多环境中的应用程序产生影响，因为MacOS、许多Linux发行版和许多服务器应用程序已经支持UTF-8。但是，在其他环境中也存在风险，最明显的是，依赖默认字符集的应用程序在处理未指定默认字符集时生成的数据时会表现不正确。数据损坏可能会悄然发生。预计主要影响将落在亚洲地区Windows系统的用户身上，可能还会落在亚洲和其他地区的某些服务器环境上。
• JavaAPI文档中的代码片段，包括为JavaDoc的标准Doclet引入@snippet标记，以简化API文档中示例源代码的包含。该计划的目标之一是通过提供对源代码片段的API访问来促进源代码片段的验证。虽然正确性是作者的责任，但JavaDoc和相关工具中增强的支持可以使其更容易实现。其他目标包括启用现代样式，如语法突出显示，以及名称与声明的自动链接，以及更好地支持IDE创建和编辑代码段。该提案指出，API文档的作者经常在文档注释中包含源代码片段。

原文：https://www.infoworld.com/article/3630510/jdk-18-the-new-features-in-ja…

本文：https://jiagoushi.pro/node/1810