错误信息如下： java.lang.NullPointerException at com.usvisatrack.common.data.tests.jpa.UserRepositoryTest.testInsert(UserRepositoryTest.java:57) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) 上面的错误信息提示的就是因为 userRepository 为空，我们不能进行数据库有关的操作。 问题和解决 尽管我们在测试中定义了： private UserRepository userRepository; 很显然的是 Spring 没有 Autowired。 主要原因是因为 Spring 的测试严重依赖 Spring。 我们没有对 Spring 进行初始化，是不能进行测试的。 因为我们这个代码是对 JPA 进行测试的，因此只需要在测试代码的最上端添加 @DataJpaTest 这个注解就可以了。     需要注意的就是，对 Spring 进行任何测试，包括测试 JPA 或者 API ，都需要对 Spring 进行初始化。 https://www.ossez.com/t/spring-data-repository/14071

@DataJpaTest 这个注解主要用来在 Spring 项目中测试 JPA 数据源。 默认情况下，带有 @DataJpaTest 注解的测试使用嵌入式内存数据库。 因此 @DataJpaTest 这个注解还是有点坑的。 默认数据库 默认采用的是嵌入的 H2 数据库。 就算你配置了数据库链接，如果你不使用下面的注解的话，@DataJpaTest 还是会使用配置的默认数据库。 使用注解： @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) 来让你的程序只使用你提供的数据库连接来进行连接。 事务 @DataJpaTest 具有事务性，会自动回滚插入数据。 如果你的不进行配置的话，你会发现你插入的数据没有办法在数据库中出现。 解决办法就是在方法中，提供 @Commit 注解。 然后再对数据库中的数据进行校验，这个时候数据是不会回滚的。 从日志中，我们也可以看到，插入的数据被回滚了。     当我们提供 Commit 这个注释后，在日志中明确的提示已经提交了。     表 hibernate_sequence 这是因为我们在数据库实体类配置的时候，没有指定主键策略。 在默认情况使用的是 Auto。 如果使用 Auto，Hibernate 将会使用 Oracle 的方式来自增的。 如果需要使用 Mysql 的话，你的实体类需要将主键策略修改为： @GeneratedValue(strategy = GenerationType.IDENTITY) 因为我们实体类使用了继承 AbstractPersistable。     因此我们可以通过修改 application.properties 来实现。 将参数设置为 false spring.jpa.hibernate.use-new-id-generator-mappings=false     这样就会对主键的策略进行修改了，我们就可以避免上面的这个问题了。   https://www.ossez.com/t/datajpatest/14070

提示的错误信息为： Caused by: java.lang.IllegalArgumentException: LoggerFactory is not a Logback LoggerContext but Logback is on the classpath. Either remove Logback or the competing implementation (class org.apache.logging.slf4j.Log4jLoggerFactory loaded from file:/C:/Users/yhu/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.8.2/log4j-slf4j-impl-2.8.2.jar). If you are using WebLogic you will need to add 'org.slf4j' to prefer-application-packages in WEB-INF/weblogic.xml: org.apache.logging.slf4j.Log4jLoggerFactory 错误界面如下：     问题和解决 这个又是典型的 Spring Boot 版本冲突的问题。 在 Pom 文件中，可能有 Log4j 的包。 这个会导致 Spring Boot 没有办法绑定日志。 在我们的项目中就是因为绑定了下面的版本而导致的错误：     如果我们上面的内容从 Pom 文件中删除后，问题解决了。   https://www.ossez.com/t/spring-boot/14069

启动 Spring 项目的时候提示下面的错误信息： Exception in thread "main" java.lang.IllegalArgumentException: Cannot instantiate interface org.springframework.context.ApplicationListener : org.springframework.boot.context.logging.LoggingApplicationListener at org.springframework.boot.SpringApplication.createSpringFactoriesInstances(SpringApplication.java:461) at org.springframework.boot.SpringApplication.getSpringFactoriesInstances(SpringApplication.java:443) at org.springframework.boot.SpringApplication.getSpringFactoriesInstances(SpringApplication.java:436) at org.springframework.boot.SpringApplication.<init>(SpringApplication.java:267) at org.springframework.boot.SpringApplication.<init>(SpringApplication.java:245) at org.springframework.boot.SpringApplication.run(SpringApplication.java:1317) at org.springframework.boot.SpringApplication.run(SpringApplication.java:1306) at com.usvisatrack.common.data.Application.main(Application.java:18) Caused by: java.lang.NoClassDefFoundError: org.springframework.context.event.GenericApplicationListener at java.base/java.lang.ClassLoader.defineClassImpl(Native Method) at java.base/java.lang.ClassLoader.defineClassInternal(ClassLoader.java:466) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:427) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:1110) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:898) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:806) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:764) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:1074) at java.base/java.lang.Class.forNameImpl(Native Method) at java.base/java.lang.Class.forName(Class.java:417) at org.springframework.util.ClassUtils.forName(ClassUtils.java:284) at org.springframework.boot.SpringApplication.createSpringFactoriesInstances(SpringApplication.java:454) ... 7 more Caused by: java.lang.ClassNotFoundException: org.springframework.context.event.GenericApplicationListener at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:766) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:1074) ... 21 more 下面的界面为错误的信息：     问题和解决 上面的问题简单来说就是在你的 Spring 项目中有 2 个版本的 Spring ，你需要找到 Maven 的配置文件中确定只有一个 Spring Boot 的版本。 找到你的 pom配置文件，确保只有一个 Spring Boot 在你的配置文件中。     我的情况是上面老的 spring-context 和新版本的 Spring Boot 冲突了。 删掉上面的依赖就可以了。 https://www.ossez.com/t/spring-loggingapplicationlistener/14067

在本文章中，我们将会解决在 Spring Boot 运行测试的时候，得到 NoSuchMethodError 和 NoClassDefFoundError 的 JUnit 错误。 这个错误的原因，通常是因为我们的系统中有 2 个不同的 JUnit 版本，在运行的时候 JUnit 不知道使用哪个版本来运行。 同时，也有可能是因为 JUnit 测试运行使用的的版本和框架运行的版本不同而导致的。 错误的界面如下     Spring 项目中的 JUnit NoClassDefFoundError 错误 让我们假设我们的 Spring Boot 项目中使用的 Boot 版本为 2.1.2。 基于上面的 Spring Boot 版本，我们可以使用的 JUnit 测试的版本为 5.3.2，这个版本就是 spring-boot-test 项目中使用的依赖。 假设，现在我们还是希望使用 Spring Boot 2.1.2. 但是，我们希望使用 JUnit 5.7.1 版本来进行测试。 一个可行的办法就是在你的 POM.xml 文件中添加 junit-jupiter-api, junit-jupiter-params, junit-jupiter-engine, 和 junit-platform-launcher 依赖。 需要添加的代码如下： <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-api</artifactId> <version>5.7.1</version> <scope>test</scope> </dependency> ... 如果这个时候，你尝试运行测试的话，你将会得到 NoClassDefFoundError 错误： [ERROR] java.lang.NoClassDefFoundError: org/junit/platform/commons/util/ClassNamePatternFilterUtils 如果你不想使用 5.3.2 的版本，想升级到 JUnit 5.4.0 版本，当你再次运行测试的时候，我们还是会得到 NoClassDefFoundError 和 NoSuchMethodError 错误。 错误原因 不管你使用 JUnit 的何种版本，只要你使用的版本和 Spring Boot 中使用的版本不一致的话，我们都会得到 NoClassDefFoundError 这个错误。 这个错误的主要原因是我们的 classpath 中最后有 2 个不同版本的 JUnit。 我们的项目使用的是 JUnit (5.7.1) 版本进行编译的，但是在运行的时候使用的 (5.3.2) 这个版本来运行的。 上面的情况的结果就是 JUnit launcher 尝试用老版的 JUnit 版本中不存在的类来运行。 知道上面的原因后，我们下面来看看可以使用的一些修复方法。 主要解决思路就是让整个项目中只有一个 JUnit 的版本。 修改办法 - 重写 Spring Boot 中使用的 JUnit 这个可能是最有效的方法了。 Spring Boot 可以让你调整属性文件中的版本配置来配置使用不同的版本，你只需要简单的调整 pom.xml 中的版本属性中的版本号，就可以让 Spring Boot 来使用你指定的版本了： <properties> <junit-jupiter.version>5.7.1</junit-jupiter.version> </properties> 如果你的 pom 文件中没有这个属性的话，添加一个就可以了。 然后将下面的内容添加到你的 pom 文件中，在这里我们只需要一个 junit-jupiter 就可以了。 <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter</artifactId> </dependency> 上面的配置将会包含 junit-jupiter-api, junit-jupiter-params, 和 junit-jupiter-engine. junit-platform-launcher 依赖，通常只是在编程运行 JUnit 的时候需要。 针对 Gradle project 的项目，我们可以使用下面的属性配置 ext['junit-jupiter.version'] = '5.7.1' 针对其他的项目 在上面的部分，我们了解了如何在 Spring Boot 中来修正 NoSuchMethodError 和 NoClassDefFoundError 错误，这个错误在 Spring Boot 中属于比较常见的错误。 如果是其他不使用 Spring 的 Maven 项目，我们也可以通过上面的方法来修改冲突。 和 Spring Boot 中的修改方法是一样的，通常都是因为版本冲突的原因导致的。 我们可以通过分析 Maven 中的依赖来找到冲突的版本进行版本调整就可以了。 结论 在本文章中，我们对 Spring 常见的 NoSuchMethodError 和 NoClassDefFoundError JUnit 错误进行了一些阐述，并且针对这个问题提供了解决方案。   https://www.ossez.com/t/spring-boot-junit-nosuchmethoderror/14066

首先需要确定的是你的系统中已经安装了 JDK 可以输入 java -version 命令进行查看。     然后可以通过项目的配置 JDK 进行查看。     更换 JDK 版本 选择上面的添加 JDK 版本，然后选择 IBM Semeru 在你本地计算机上的安装路径即可。 可以看到添加的版本为 IBM-11 的版本。     如果只想在计算机中保留一个版本，可以将其他的版本删除掉。 单击应用即可。 如果你的老项目已经设置了 JDK，你需要对每个项目使用的 JDK 都进行更改才可以。 随后，我们用几个老的项目跑了编译和测试，完全没有什么问题。 https://www.ossez.com/t/intellij-idea-ibm-semeru-jdk/14062

可以访问：IBM Developer 来下载。 在界面中，选择你需要的版本和操作系统。 semeru 有认证版和非认证版，主要是因为和 OpenJ9 的关系和操作系统的关系而使用不同的许可证罢了，本质代码是一样的。 在 Windows 下没有认证版，直接下开源版就行。     可以下载 msi 包，让安装程序直接进行配置。 运行安装程序 双击安装程序，进行安装。 同意许可证 设置相关环境变量 这里可以选择让安装程序设置 JAVA_HOME 环境变量和覆盖 Oracle 安装程序在 Windows 中创建的键值。 如果你的操作系统中安装了多个 JDK 的话，建议不要让安装程序设置你的 JAVA_HOME 你可以自己进行设置。 下一步继续安装。 获得管理员权限进行安装 安装需要管理员权限，在这里单击下一步继续。 安装进程 完成安装 校验安装 运行 java -version 来查看安装的版本。 C:\Users\yhu>java -version openjdk version "11.0.16" 2022-07-19 IBM Semeru Runtime Open Edition 11.0.16.0 (build 11.0.16+8) Eclipse OpenJ9 VM 11.0.16.0 (build openj9-0.33.0, JRE 11 Windows 11 amd64-64-Bit Compressed References 20220804_420 (JIT enabled, AOT enabled) OpenJ9 - 04a55b45b OMR - b58aa2708 JCL - ab74d97849 based on jdk-11.0.16+8) 通过上面的代码你可以看到安装的 JDK 和 JVM 的信息。 你可能不知道程序具体安装到哪里去了。 你可以输入 PATH 进行查看。 默认的安装路径为：C:\Program Files\Semeru\jdk-11.0.16.8-openj9 你可以为你的操作系统设置 PATH 和 JAVA_HOME 环境变量。     我的计算机中还注册过 RedHat 的 JDK，在这里我们可以删除掉，只保留一个，以避免冲突。 在变量在用户的环境变量中进行设置。     至此，Semeru 在 Windows 的安装配置已经完成了。   https://www.ossez.com/t/ibm-semeru-windows/14061

自从 Oracle 收购 Sun 以后，Java 世界也变了不少。 好在 Oracle 还开源了个 OpenJDK，并且很多东西都变了。 OpenJDK 就是一个桶，什么都可以往里面装，各大公司又纷纷推出自己的 JDK，简直可以直呼看不懂。 OpenJDK 在 Windows 环境下的诟病就是不好装，不知道怎么装。 救民水火的 RedHat RedHat 应该注意到了这个情况，在自己的开发网站中推出了 RedHat OpenJDK 下载。我的本地开发环境就用的 RedHat 下载 OpenJDK。 挺好用的。 如果你怕麻烦，直接用这个 JDK 也没啥问题。 从安装的环境中看不出来 JVM 用的是那个版本，应该是 HotSpot 吧。 如果错了请大家纠正。 IBM 在实际世界中，推动开源的还有 IBM。 这个名字不应该被忘记，虽然近些年有点廉颇老矣的意思了。 IBM 推出了 semeru， 下载页面是 IBM Developer 上面使用的 OpenJDK 和 OpenJ9 的虚拟机。 因为同事的新机器要配置 JDK，突然问我要什么 JDK，我才从 IDEA 上面找到的。 上面还有一个 Eclipse Temurin 下载，你可能就有点困惑，我到底要下载那一个了。 下载地址为： Latest releases     为什么有 2 个版本 为什么这里有 2 个 OpenJDK 版本的下载呢？ 经过考古，主要原因是这 2 个 OpenJDK 的 JVM 虚拟机版本不一样。 Eclipse Temurin 使用的是 Hotspot 的虚拟机。 IBM Semeru 使用的是 OpenJ9 的虚拟机。 IBM 和 Eclipse 基金会的渊源 IBM 将自己的开源的东西捐献给了 Eclipse 基金会。 可以说没有 IBM 就没有 Eclipse，Eclipse 就是 IBM 成立的，但是 Eclipse 又是独立运作的，捐献出去的东西也和 IBM 没有什么太大关系了。全部都是 Eclipse 基金会维护的。 IBM Semeru 认证 IBM Semeru 下面又出现了一个认证的版本。 Eclipse Temurin 提供 OpenJDK + Hotspot 映像，IBM Semeru Runtimes 将提供 OpenJDK + Eclipse OpenJ9 映像的开放和认证 (JCKed) 版本。 这是一个令人困惑的故事和过渡，我会尝试添加一些背景。到目前为止，AdoptOpenJDK 一直在使用 Hotspot 和 OpenJ9 VM 生成 OpenJDK 二进制文件。 随着 Adopt 迁移到 Eclipse，法律限制阻止了新的 Eclipse Adoptium 小组生产/发布基于 OpenJ9 的二进制文件。 因此，IBM 将以 IBM Semeru Runtimes 的家族名称生产基于 OpenJ9 的 2 种风格的二进制文件，即 Open 和 Certified。本质上相同的二进制文件，在不同的许可证下发布。 下载 IBM Developer 就可以开始使用了。 IBM Semeru Runtimes将有两个版本，具有不同的许可证：IBM Semeru Runtime开放版具有开源许可证（GPLv2+Classpath扩展），而IBM Semeru Runtime认证版具有IBM许可证。IBM Semeru Runtime都通过了全面的Eclipse AQAvit质量保证测试套件，以提供一个稳定和可支持的引擎，可以运行任何种类的Java应用程序。 正如其名称所示，IBM Semeru Runtime认证版也经过了Java TCK认证。 为了支持新的命名规则，从2021年7月的更新版本开始，当前的IBM SDK，即Java技术版11，将更名为IBM Semeru Runtime认证版。 上面的话真的很绕。 我的理解就是因为 OpenJ9 已经捐献给了 Eclipse 基金会了。从法律角度来说和 IBM 已经没有什么关系了，这个是属于 Eclipse 基金会的东西。 IBM 为了避免法律上面的麻烦搞了个认证版本。 这个认证版本和不认证版本的代码和结构都完全相同，只是 IBM 可能希望通过认证版本提供一些更多的支持吧。 对于开发人员来说，都一样没区别，放心用。 写在最后 Java 世界有了不少的变化。 IBM 是我一直比较敬佩的公司，从 Dev2Dev 网站到对 Java 世界的支持。 以及捐献给 Eclipse 基金会的很多产品，都让人值得怀念。 对比 Oracle 的贪得无厌，微软的小肚鸡肠，IBM 和 RedHat 都值得大家为他们点个赞。 虽然现在 Java 的版本已经被搞得乱得不要不要的了。 简单总结下就是，如果你希望： OpenJDk + HotSpot 虚拟机： 下载 Eclipse Temurin 或者 RedHat 版本。 OpenJDK + OpenJ9 虚拟机：下载 IBM Semeru 版本（认证不认证都一样）   https://www.ossez.com/t/openjdk-jvm/14058

OpenJ9 简单来说就是 JVM 的其中一个开源版本。 如果你默认安装的是使用 Oracle 的话，那么跑不了会看到一个 HotSpot，这个就是 Oracle 使用的版本。 这个 JVM 版本是从 SUN 系统开始就使用的版本。 Java 在开源的时候因为这个 JVM 版本有些内容是不开源的，所以 JVM 其实并不是开源的，当落入 Oracle 手之后，这个 HotSpot 自然就归了 Oracle。 按照 Oracle 的尿性，这个肯定是需要收费的了。 或者 JVM 不收费，一旦上了 Oracle 的贼船，下来就不那么容易了。     OpenJ9 好在我们现在有了 OpenJ9 了。不管怎么样，我们还是得感谢感谢 IBM。 在 IBM 中的 Java 机器中，是不使用 HotSpot 虚拟机的。 JVM是Java的跨平台性实现的基础，不同平台上标准统一的JVM提供了相同虚拟运行环境，使得Java应用不用做(或很小的）修改在各个JVM上都能运行。 IBM Technology for Java Virtual Machine是IBM自己开发的一款JVM，它支持在当前流行的大部分平台上的安装和使用，这其中就包括IBM i。 除去IBM Technology for Java Virtual Machine,在一些文档中，也许你还读到过这些名称：IBM Virtual Machine for Java, IBM JVM，IBM J9 VM, J9 JVM, 以及IT4J。 而这不同的名称中，J9显得更特别一点。为什么会有J9这个名字呢？这与这款JVM的出身有关，它最早是由IBM Ottawa实验室一个Small Talk的虚拟机扩展来的。 那时候，这个虚拟机有一个bug是因为8k值定义错误引起，工程师们花了很长时间终于发现并解决了这个错误，此后这个版本的虚拟机就被称为K8了。于是，后来出现的支持Java这个版本的虚拟机就被称为J9了。 Eclipse OpenJ9 是 OpenJDK 的替代品吗 不是。Eclipse OpenJ9 是一个 Java 虚拟机(JVM)，它是运行 Java 应用程序的引擎，而 OpenJDK 是一个完整的开发工具包，包括JVM、Java 基础类库。默认情况下，OpenJDK 使用名为 Hotspot 的 JVM。简单地说，OpenJ9 是一个 JVM 替代方案，可将其作为 OpenJDK 二进制文件的一部分。 Eclipse OpenJ9 是否与 Hotspot 相同 Hotspot 和 Eclipse OpenJ9 都是可以包含在 OpenJDK 中的 Java 虚拟机，但它们都具有不同的功能。根据所遵循的构建过程，可以构建包含 Eclipse OpenJ9 或 Hotspot 的 OpenJDK 二进制文件。 为什么要使用 Eclipse OpenJ9 而不是默认的 JVM 如果你正为应用程序寻找企业级的运行时环境，建议使用 Eclipse OpenJ9 构建 OpenJDK。这个高性能、可扩展的虚拟机是许多 IBM 企业软件产品的核心，所以它的血统就是为企业应用环境而生的。 另外，你还可以调整 OpenJ9，以进一步改进特定场景下 Java 应用程序的性能。例如，可以切换垃圾回收策略以管理不同类型工作负载的内存。 当 IBM 把 J9 捐给 Eclipse 基金会以后，这个版本就被称为 OpenJ9了。 OpenJ9 是完全开源的，官方地址为：https://www.eclipse.org/openj9/ 所有 OpenJ9 的源代码都可以在 GitHub 上找到。   https://www.ossez.com/t/openj9/14057

大部分情况下我们都使用这几个修饰来修饰方法。 当然对类来说，相信大部分都默认使用 Public，大部分人都不去纠结。 Public： 简单来说就是谁都可以访问，你写个类除了特殊要求，当然都是希望大部分人用的。 Private：私有。 除了class自己之外，任何人都不可直接使用。简单来说就是一个方法，你只希望自己的这个类可以用，不希望这个方法在其他类中使用。Private 这个在类中的私有方法中定义比较多。 Protected：这个就是最纠结，简单来说就是这个修饰的方法使用范围比 Public 小，但是又比 Private 大。对于其他的外部类，protected 就变成 private。 官方的：Controlling Access to Members of a Class (The Java™ Tutorials > Learning the Java Language > Classes and Objects) 文章对上面几个修饰有了定义。 也顺便偷了一张图。   对我们来说 Protected 和 Public 也差不多了，没有很多奇葩需求的话，你就 Public 算了，省得纠结。 这就是为什么你看很多人的代码的时候，大部分都是 Public 和 Private，用 Protected 修饰的方法远没有这 2 个这么多。 本来不想纠结这几个关键字的，无奈学院派的人非要纠结，有点讨厌。 对日常的业务逻辑开发，只要是类里面的方法，你就 Private，因为别人也不一定用得到。 如果你希望其他人用，就 Public，并且单独做成类，让别人直接调用吧，不要过于纠结。 https://www.ossez.com/t/java-public-private-protected/14056