Solution: Problems with Kotlin

Well, the solution to [1] is obviously that you are missing a "&&".

This causes Kotlin to assume the expression:

it.address.country == "United Kingdom"

... is the expression that needs to be returned. This causes the code to spit out all people currently in the United Kingdom.

It took me a little while to notice the problem. My IDE didn't help in the slightest.

References

[1] Problems with Kotlin

https://randomthoughtsonjavaprogramming.blogspot.com/2024/11/problems-with-kotlin.html

Problems with Kotlin

So, I was working and it didn't work.

And I really could not understand why.

Here's the code:

    @Test
    fun test() {
        val addressInNetherlands =
            Address(housenumber = 11L, street = "Kerkstraat", city = "Amsterdam", state = null, country = "Netherlands")
        val addressInEngland = Address(12, "Morsestreet", "London", null, "United Kingdom")
        val anotherAddressInEngland = Address(28, "Trinity Ln", "Cambridge", null, "United Kingdom")
        val addressInAmerica = Address(23, "32nd Street", "Columbus", "Ohio", "United States of America")

        val mrBear = Person("Mr.", "Bear", 50, addressInNetherlands)
        val mrBell = Person("Bell", "Graham", 55, addressInAmerica);
        val mrBoole = Person("George", "Boole", 82, addressInEngland);
        val lordKelvin = Person("William","Kelvin",84, anotherAddressInEngland);

        val addressBook = listOf(mrBear, mrBell, mrBoole, lordKelvin)

        var findMrBooleInEngland = addressBook.filter {
            it.firstName == "George" &&
                    it.lastName == "Boole"
                    it.address.country == "United Kingdom"
        }

        assertThat(findMrBooleInEngland).hasSize(1)
    }

Why does the assert fail? (it's programmer error, but almost invisible)

Solution in the next blog post.

Peak of Complexity

So, I was at Devoxx 2024. During the opening keynotes, Brian Goetz spoke regarding Peak of Complexity.

You can find it below at [1].

It's important to me on a personal level, as I do tend to make things more complex than they should be.

Often times, it means I overengineer my solutions and program for exceptional situations that are unlikely to occur.

One of those overengineered ways of thinking happened today.

A colleague asked if he was doing it right. He was reading in an XML file of about 5000 entries in a Batch process.

1. First I thought we should use a stream, build the stream ourselves, so we can have an XMLReader that provides us each piece of information we need without loading the entire thing in memory.
2. Then I found out that it's bloody hard to make your own streams. A default builder in the JDK uses a SpinedBuffer which is basically an ArrayList containing ArrayLists. Which means the entire thing is still read into memory.
3. So I thought I could use a simple Consumer. The Consumer gets a new one from the XMLReader when he has one available.
4. Then I found out that that doesn't really mesh well with the Batch Reader process. So I started thinking about using an iterator, instead of an Consumer.
5. But in the end, after everything's said and done, the XML file contains only 5000 entries, and the entries are not very complex and the whole thing could be put into a List of simple POJOs. So now it's just a simple List.

Once again, in the end, I've managed to whittle it down to the simplest solution, but it would be nice if I started from the simplest solution, and only increase complexity when needed.

I guess I still need to work at it.

References

[1] Postcards from the Peak of Complexity by Brian Goetz

https://www.youtube.com/watch?v=Yiye8lqh0Ig