Thursday, 27 September 2018

Mutable members should not be stored or returned directly

But SonarLint is complaining about it, so I refactored it into this:

It's high time this old codebase gets converted to LocalDates.


SonarSource - RSPEC-2384

Monday, 24 September 2018

Using a composite key in a map

Once again I stumbled upon old code, that could use some refactoring.

It took me and my colleague a few seconds to process what the software designer had in mind when he did this.

As it was up to me to add another field to the construction, making it even more terrible than it was, it was time for a refactoring.

Refactored solution

We quite quickly came up with using a Composite Key, which of course is the default way to deal with this sort of thing.

Added benefit

There was some trickery going on to properly deal with NULL keys (which are sometimes not allowed in a Map implementation1).

This disadvantage now disappears with this nice composite key.

Test setup

I tested it with a list of cars, and I do not wish to withhold the test setup:

Fuzzy matching

Of course it is quite easy to just match on some of the criteria. In this case, we could use a Map containing Lists, where the composite key used has empty fields, and would cause a list of cars to be returned and a full composite key (all search criteria) would just yield a list containing one specific car.

If we wish to use fuzzy matching, we are in a bit of a bind.

I'm pretty sure there are always other (perhaps even better) ways of doing this. If you know of some, let me know.

I'm always interested.


[1] Oracle JavaDoc - Map Implementation
Different Types Of Cars List

Wednesday, 12 September 2018

Pop quiz answer: varargs

The answer for the VarArgs Pop Quiz.

Testcase 1 : [Ljava.lang.String;@579bb367 is not null and has length 0
Testcase 2 : args is null
Testcase 3 : [Ljava.lang.String;@1de0aca6 is not null and has length 2
     first element is null

Process finished with exit code 0

The reason for the quiz is that there's a potential NullPointerException in there, that you need to be aware of.

According to reference [1], if the argument provided is compatible with String[], it is assumed that that is what you meant. And null is always compatible with any T[].

Also interesting enough and just to drive the point home, it means that the method signatures below are identical and Java will give you a big fat warning that you defined the same method twice.

public void vars(String... args);

public void vars(String[] args);


[1] Oracle Java Language Spec - Evaluate Arguments
Blogpost - Pop Quiz: Varargs

Friday, 7 September 2018

Pop quiz : varargs

Pop quiz: what is the output of the following program:

The answer in the following blog post.