Improper Use of Softly Asserts

I don't really like Softly Asserts, and I notice that a lot of developers at work seem to use it all the time.

And since it's Christmas today (Merry Christmas!), let's get into the spirit of the season by testing if there is a Miracle on 34th Street.

We are going to use SoftlyAssertions with the following test written below:

And it looks fine if the tests run properly.

But when the tests fail, likely as not we see NullPointerExceptions instead of useful asserts.

Let's try to fail the test, by removing the town.

Street thirtyfourthStreet = new Street("34th Street", null);

And lo and behold, we get this:

java.lang.NullPointerException at com.mrbear.testingtests.SoftlyAssertionTest.testMiracleAt34thStreet(SoftlyAssertionTest.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:571)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:707)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:979)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.privateRun(TestRunner.java:648)
at org.testng.TestRunner.run(TestRunner.java:505)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:455)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:450)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:415)
at org.testng.SuiteRunner.run(SuiteRunner.java:364)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:84)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1187)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1116)
at org.testng.TestNG.runSuites(TestNG.java:1028)
at org.testng.TestNG.run(TestNG.java:996)
at com.intellij.rt.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:66)
at com.intellij.rt.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:110)

I really would like for SoftAssertions to only be used during checking of simple properties within an object, thanks!

And not this cross-boundary stuff.

Java Alternatives in Fedora Core - Followup

This is a followup of the blogpost Java Alternatives in Fedora Core.

The instructions in the blogpost also hold for Java 13.

[root@localhost ~]# dnf install java-13-openjdk
[root@localhost ~]# dnf install java-13-openjdk-devel

Unfortunately, there was a snag with Maven, so I thought I'd document it here.

Maven

Maven stubbornly remained firmly pointing to java 8, whatever alternative I picked in my Fedora Core.

[mrbear@localhost ~]$ mvn -version
Apache Maven 3.5.4 (Red Hat 3.5.4-5)
Maven home: /usr/share/maven
Java version: 1.8.0_232, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232.b09-0.fc30.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.3.11-200.fc30.x86_64", arch: "amd64", family: "unix"

Well, trying to compile a java application with version 13 in the pom.xml, is NOT going to work when your Maven is using openjdk 8.

Really no surprise there.

You get:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project mrbearapp: Fatal error compiling: invalid target release: 13 -> [Help 1]

It turns out I really need to set JAVA_HOME?

Editing .bashrc to add the following:

export JAVA_HOME=/usr/lib/jvm/java-13

Now I get:

[mrbear@localhost ~]$ mvn -version
Apache Maven 3.5.4 (Red Hat 3.5.4-5)
Maven home: /usr/share/maven
Java version: 13.0.1, vendor: N/A, runtime: /usr/lib/jvm/java-13-openjdk-13.0.1.9-2.rolling.fc30.x86_64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.3.11-200.fc30.x86_64", arch: "amd64", family: "unix"

All is as it should be, and we are merrily on our way.