在 2022 年发布版本中，IntelliJ IDEA 针对代码默认开启了作者提示功能。 主要用来方便的知道上面的代码最后是谁写的。 当然，你也可以对这个配置来进行调整。 选择后右键，在右键中你可以选择进行配置显示这个还是不显示这个。 在默认情况下，这个是开启的。 https://www.ossez.com/t/intellij-idea-2022/14012
使用 Jenkins 的目的就是为了尽量让编译和集成的部署自动化。 通常在部署成功和配置后，通常是想要通过事件自动触发编译，我们通常有很多种办法可以做。 比如使用 webhook 的方式来做。 检查 SCM 另外一种方法就让 Jenkins 每隔一段时间来自动检查下代码，如果代码有修改的话就触发编译。 通过对上面的选择就可以完成这个操作了。 需要注意的是 Jenkins 采取了和 Cron 类似的语法，但是又有一点点不同。 上面的语法就是每 5 分钟 Pull 一次。 在 Jenkins 中可以看到本次编译是如何被触发的。 从上面的图片中可以看到是通过系统的 SCM 改变来触发的编译。 https://www.ossez.com/t/jenkins/14010
Gitea 和 Jenkins 集成成功，提交代码的话将会进行编译。 如果编译成功后将会显示编译成功的情况。 如下图所示： 从 Jenkins 上面，我们可以看到的是触发的 pipeline 编译。 当所有的都配置好后，每次 PUSH 都会触发一次编译，通常能够通过这次编译来了解代码的情况。 https://www.ossez.com/t/gitea-jenkins/14009
最近在运行项目的时候 Jetty 出现了一个比较奇葩的错误。 一直显示是 503 错误，但是又找不到错误的原因。 后来通过查看可能的原因是 Jetty 的版本和 JDK 的版本没有办法支持导致的。 从上面的图片我们知道，当前运行 Jetty 的版本是 9.4。 但是我们服务器上装的 JDK 版本是 11。 Jetty 9 是没有办法运行在 JDK 11 上的。 上面的图片显示了 Jetty 可以支持的容器的版本。 在部署服务的时候，这个比较重要，否则你会遇到一些莫名其妙的错误。 https://www.ossez.com/t/jetty-503/14006
发现新版本的 IntelliJ IDEA 已经推送了。 https://www.ossez.com/t/2022-1-intellij-idea/14005
有关错误的信息如下： 问题和解决 有关这个问题是因为你的服务器上可能使用了 JDK 11 的版本。 但是最新的 Archiva 只能够支持 1.8 的版本。 如果你的服务器缺包的话，就会出现上面的错误。 你可以尝试使用 Archiva 自己进行编译，或者部署到 1.8 的 JDK 版本上，或者等到 Archiva 3.0 的版本后再开始用吧。 我们看到 Git 的代码库中，有关 Archiva 正在尝试使用 11 的 JDK 版本进行编译。 但是，具体需要什么时候才能用，就不太清楚了。 https://www.ossez.com/t/archiva-jaxbexception/14002
如果我们的对象为空对象的时候，我们再使用 toString() 方法，我们将会得到空对象的异常。 这个对象有可能就是 String 对象，也有可能是其他的对象。 如下面的 2 行语句： Object obj = null; obj.toString(); 如果你执行上面 2 行语句的话，铁定会抛出下面的空对象异常。 如何让 Java 能够 toString 又不抛出异常呢？ 解决方法 我们可以使用 Apache commons.lang3 提供的 toString() 方法。 如下面显示的使用用例： Object obj = null; ObjectUtils.toString(obj, StringUtils.EMPTY); ObjectUtils.toString(obj, ()->StringUtils.EMPTY); 如果我们输入的对象为 NULL 的话，上面的语句将会输出一个指定的字符串而不抛出空异常。 需要注意的是写法： ObjectUtils.toString(obj, StringUtils.EMPTY); Apache commons.lang3 项目官方提示这个方法将会在后续的版本中被丢弃。 原因是这个方法已经被 java.util.Objects.toString(Object, String) 方法替代了。 如果你使用的是 Java 7 以上版本的话，建议你使用 java.util.Objects.toString 方法。 你可以简单的 Objects.toString 就可以了： assertThat("null").isEqualTo(Objects.toString(obj)); assertThat("").isEqualTo(Objects.toString(obj,StringUtils.EMPTY)); 对比上面 2 个方法的不同，第一个方法是如果为 Null 的话，就直接输出字符串 null。 第二个方法是如果为空的话，将会用另外一个字符串去替换。 总结 通过上面的代码和用例，我们对在对象 toString 的时候可能出现的 Null 对象异常情况进行了解说。 并且展示了可以使用的一些方法。 https://www.ossez.com/t/java-tostring/14000
在判断输入的字符串是不是一个数字的时候，我们通常用的最多的方法就是 ： NumberUtils.isNumber("12"); 但是这个方法将会在 Lang 4.0 版本中被丢弃。 可以使用的替代方法为：isCreatable(String) 通过查看源代码，我们可以看到 isNumber 也是调用 isCreatable 方法的。 @Deprecated public static boolean isNumber(final String str) { return isCreatable(str); } isCreatable 方法首先是对输入的字符串拆分成字符，然后对每一个字符进行判断，以确定输入的字符串是不是数字，是不是可以将 String 转换为数字类型。 通过上面的方法，我们看到判断的方法还是有点复杂的。 https://www.ossez.com/t/apache-commons-lang3-isnumber-lang-4/13990
本文对在 Junit 测试中如何对异常进行断言的几种方法进行说明。 使用 Junit 5 如果你使用 Junit 5 的话，你可以直接使用 assertThrows 方法来对异常进行断言。 代码如下： Exception exception = assertThrows(NumberFormatException.class, () -> { new Integer("one"); }); System.out.println(exception); 使用 AssertJ 使用 AssertJ ，你可以有不少方法进行选择。 我们尝试使用 assertThatThrownBy 和 assertThatExceptionOfType 2 个方法。 这 2 个方法的写法有点不一样，但是整体效果是差不多的。 考察如下代码： // AssertJ assertThatThrownBy assertThatThrownBy(() -> { new Integer("one"); }).isInstanceOf(NumberFormatException.class).hasMessageStartingWith("For input string"); // AssertJ assertThatExceptionOfType assertThatExceptionOfType(NumberFormatException.class).isThrownBy(() -> { new Integer("one"); }); 上面代码中，对有关断言的使用进行了一些说明。 https://www.ossez.com/t/junit/13989
本页面主要来说说 AssertJ 的异常断言。 概述 在本快速导航中，我们主要来聊聊的 AssertJ 的异常（exception）断言。 有关 AssertJ 的项目，请访问 AssertJ / Fluent assertions for java 页面。 不使用 AssertJ 如果不使用 AssertJ，我们需要先捕获一个异常，然后再在异常中进行断言。 例如下面的伪代码，我们捕获了一个异常，然后再进行判断。 try { // ... } catch (Exception e) { // assertions } 但是，如果程序在执行的时候没有抛出异常，在上面的用例中，测试将会通过。 为了让断言能够被执行，为什么我们还需要手动触发一个异常呢？ 使用 AssertJ 在 Java 8 以后的版本，我们可以通过使用 AssertJ 和 lambda 表达式，非常容易的对异常进行断言处理。 使用 assertThatThrownBy() 方法 让我们看看下面的代码将会抛出 IndexOutOfBoundsException 异常： 这是因为我们定义一个 List 的长度是 2 ，但是我们有一行代码将会访问 List 的第 3 个元素，上面的代码必然会抛出一个异常。 assertThatThrownBy(() -> { ArrayList<String> myStringList = new ArrayList<String>(Arrays.asList("Strine one", "String two")); myStringList.get(2); }).isInstanceOf(IndexOutOfBoundsException.class) .hasMessageStartingWith("Index 2"); 需要注意上面的代码片段有可能会抛出一个 lambda 表达式异常。 当然，我们还可以使用 AssertJ 来提供一个链式断言，这个就是为什么我们不使用 Junit 自带断言的原因。 .hasMessageStartingWith("Index 2") .hasMessageContaining("2") .hasMessageEndingWith("length 2") .hasMessageContaining("Index 2") .hasNoCause(); 使用 assertThatExceptionOfType 方法 这个方法与上面使用的方法类似，因为我们知道这个程序执行就会抛出异常，因此我们在程序的最开始就指定了异常： assertThatExceptionOfType(ArithmeticException.class).isThrownBy(() -> { int numerator = 10; int denominator = 0; int quotient = numerator / denominator; }) .withMessageContaining("/ by zero"); 上面的方法，因为我们使用了 0 为除数，因此必定会抛出异常。 在程序最开始的时候我们就断言了这个异常。 使用 assertThatIOException 和其他的一些常用类型 AssertJ 针对 一些常用的异常进行了包装，你可以直接使用这些被包装过的异常： assertThatIOException().isThrownBy(() -> { // ... }); 和其他一些类似的异常： assertThatIllegalArgumentException() assertThatIllegalStateException() assertThatIOException() assertThatNullPointerException() 从断言中将异常分离 可选的，我们可以将异常从断言中进行分离。 分离的办法就是添加一个 when 和 then 逻辑段： // when Throwable thrown = catchThrowable(() -> { int numerator = 10; int denominator = 0; int quotient = numerator / denominator; }); // then assertThat(thrown).isInstanceOf(ArithmeticException.class) .hasMessageContaining("/ by zero"); } 上面的代码首先是抛出异常，然后对抛出的异常再进行断言判断。 结论 在这篇短文中，我们对 AssertJ 是如何进行异常断言的情况进行了简单的介绍，同时讨论了 AssertJ 进行是如何进行异常断言的。 https://www.ossez.com/t/assertj-exception/13988