So, I ran into a novell problem recently.
I've got the following Java code, which is a basic POJO following the Java Bean conventions:
private Integer orderNumber;
private Integer amount;
public Integer getOrderNumber()
{
return orderNumber;
}
public void setOrderNumber(Integer orderNumber)
{
this.orderNumber = orderNumber;
}
public Integer getAmount()
{
return amount;
}
public void setAmount(Integer amount)
{
this.amount = amount;
}
Now, I've got a Kotlin1 class that I use for testing, and I am using AssertJ2 as the library for comparing values.
At first try it looked very easy:
assertThat(get.orderNumber).isNull()
assertThat(get.amount).isNull()
This caused a serious java.lang.NullPointerException: get.orderNumber must not be null.
This is a typical Kotlin message, as Kotlin has Null safety built in. Kotlin is telling me that orderNumber may not be null. In the Java code it all seems fine, it's an Integer and nulls are allowed.
So what went wrong here?
Well, if I check out which assertThat is being used, I end up at:
public static AbstractIntegerAssert<?> assertThat(int actual) {
return new IntegerAssert(actual);
}
And so we see now that it'll automatically be downgraded to a java int. Which Kotlin intercepts as being bad-form when using nulls.
So how to fix this?
I came up with the following little ugly hack:
assertThat(get.orderNumber as Any?).isNull()
assertThat(get.amount as Any?).isNull()
Now, all of a sudden, the method called is:
public static <T> ObjectAssert<T> assertThat(T actual) {
return new ObjectAssert(actual);
}
Which is what I want.
Unfortunately this is neither obvious nor clear.
It's the price we pay for many many overloaded methods. Sometimes the compiler will just pick the wrong one.
However, to be fair, in most cases the Compiler picks the right one. This is just one of those cases, where we have to be specific.
There's some references to tickets on Kotlin in the References.
Addendum
The proper way to fix this problem, is of course, to add an @Nullable to the method in de Java class (if you can). This causes Kotlin to automatically assume it can be "null", and it therefore does not need casting.
P.S. I'm trying out a new code formatter3. It's nice in so far that it does not require additional installs, but it does add spans and styling directly. Pick your poison, I guess.
References
- [1] Kotlin Language
- https://kotlinlang.org/
- [2] AssertJ
- https://assertj.github.io/doc/
- [3] Source code beautifier / syntax highlighter – convert code snippets to HTML « hilite.me
- http://hilite.me/
- YouTrack IntelliJ - Argument of Java platform boxed type resolves to primitive parameter method signature from Kotlin
- https://youtrack.jetbrains.com/issue/KT-21285
- GitHub AssertJ - isNull assertion broken in Kotlin when calling a Java class #1115
- https://github.com/assertj/assertj-core/issues/1115
