How to improve third-party libraries with Kotlin extensions
Tags: kotlin, java, tutorial, programming
Published: 2022-12-06 21:03:36

Do you ever find yourself using a library that lacks the API you require? I've lost track of how many utility functions and adapters I've had to write that, in retrospect, should have been part of the third-party library in the first place.

This guide will not save you from having to write a utility function, but it will show you how to easily add functionality to virtually any interface offered by a third-party library. The best approach to accomplish this in Kotlin is to use the language's extension features. Extensions, as opposed to other prevalent design patterns such as decorators and adapters, allow you to add new functionality to a class or interface in a simplified manner. You don't have to use inheritance or delegation to add new functions and properties to classes. Instead, you can add them directly to the classes themselves.

Extensions can either be declared as functions or properties.

```kotlin
class Host(val name: String)

// extension function
fun Host.resolveIP() = "Resolving IP for $name"

// extension property
val Host.port
    get() = "3030 is the port for $name"
```

Once defined, the extensions can be used just like any other function or property of the class or interface to which they belong. Public member functions and properties (e.g. `name`) can be used as part of the extension.

```kotlin
fun main() {
    val host = Host("example.com")

    println(host.name) // -> example.com

    println(host.resolveIP()) // -> Resolving IP for example.com

    println(host.port) // -> 3030 is the port for example.com
}
```

The extensions are not particularly useful in this scenario because the described functionality can be incorporated into the `Host` class. On the other hand, they flourish in test frameworks like [Kotest](https://github.com/kotest/kotest) and enable the rapid development of useful add-ons like [custom matchers](https://kotest.io/docs/assertions/custom-matchers.html). Extending third-party libraries with utility functions is another prevalent use case. In the next sections, we'll zero in on this specific aspect.

## Improving Mime4J

To give you a practical example, we will improve the [Mime4J](https://james.apache.org/mime4j) library.
Mime4J can read plain [RFC822](https://datatracker.ietf.org/doc/html/rfc822) and [MIME](https://www.rfc-editor.org/rfc/rfc2045) email messages. One of its major drawbacks is that it lacks predefined methods that return the HTML and plain text parts of a message. The intrinsic complexity of knowing MIME and all of its non-standard implementations exacerbates this disadvantage.

While looking for a good solution to extract the HTML and text parts, I came across the following [code](https://github.com/apache/james-project/blob/f0da59b65a846d9c2aae8b6a5f65c92150ad93a8/server/container/util/src/main/java/org/apache/james/util/mime/MessageContentExtractor.java) hidden in the [Apache James](https://james.apache.org/) mail server: It has a 160-line class called `MessageContentExtractor` to extract the content as well as a 50-line inner static class called `MessageContent`, which is used to hold the data.

When you break down the `MessageContentExtractor`, you will see the following main conditions that identify the HTML and
plain text parts:

1. The body part has to be of type `TextBody`.
2. The `mime-type` has to be `text/plain` or `null` for the text part and `text/html` for the HTML part.
3. Furthermore, the processed part cannot be an attachment. This is determined by evaluating whether
the `Content-Disposition` is `null`. Accepting a part with an inline Content-Disposition when it lacks a CID is an
exception to this rule.

Now that we know what to look for, we can evaluate how we want to extend the Mime4J `Message` interface. From the consumer's point of view, adding two new properties, `html` and `text` looks like the best solution. Both properties return the content of their respective parts as a `String`.

```kotlin
val Message.text: String?
    get() = TODO()

val Message.html: String?
    get() = TODO()
```

### Implementing the search conditions

In the beginning, we will concentrate on point number one: find all body parts with the `TextBody` type. To actually do this, we need some background information on how the `Message` interface is structured.

```
┌───────────────────┐     ┌───────────────────┐
│      Entity       │     │        Body       │
└───────┬───────────┘     └──────────┬────────┘
        │                            │
        │   ┌───────────────────┐    │
        └───►      Message      ◄────┘
            └───────────────────┘
```

`Message` inherits from both the `Entity` and `Body` interfaces. The `Entity` interface offers the methods required to access the body (content) of a message, or the body parts in case of a multipart message. Additionally, the `Body` interface indicates that the message itself can be part of a message body. Based on the previous points, we can conclude that the `Message` interface represents a recursive data type. A message can be part of a message, which can likewise be part of another message, and so on.

As a consequence we must attach a function to the `Entity` interface in order to find the body part we are looking for. We'll call it `findTextBody`. This function will return any message body that is a text, even if it is in a text format (for example, CSS) that we are not interested in.

```kotlin
fun Entity.findTextBody(): TextBody? {
    // Check if Entity contains a TextBody. Return it if it does
    if (body is TextBody) {
        return body as TextBody
    }

    // Check if the message has multiple parts
    if (!isMultipart) {
        return null
    }

    // Call the findTextBody function recursively on all
    // body parts and return the first one that is not null,
    // or return null when no part is found
    return (body as Multipart).bodyParts
        .firstNotNullOfOrNull { it.findTextBody() }
}
```

After we've gone through the most significant section of our conditions, we can look for parts in plain text or HTML format (our second condition). Our second condition said that the message body's MIME type must be `text/plain` or `null` for the plain text part and `text/html` for the HTML part. To do this, all we have to do is add an extra condition when our function finds a `TextBody`.

```kotlin
fun Entity.findTextBody(validMimeTypes: Set<String?>): TextBody? {
    // Added mimeType condition
    if (body is TextBody && mimeType in validMimeTypes) {
        return body as TextBody
    }

    if (!isMultipart) {
        return null
    }

    return (body as Multipart).bodyParts
        .firstNotNullOfOrNull { it.findTextBody(validMimeTypes) }
}
```

Now we can add our final condition:

> Furthermore, the processed part cannot be an attachment. This is determined by evaluating whether the `Content-Disposition` is `null`. An exception to this rule is accepting a part with an inline `Content-Disposition` when it lacks a CID.

As you can see, the condition contains two parts, which we can implement by adding two extension properties so that our code stays clean and readable.

```kotlin
private val Entity.isNotAttachment
    get() = dispositionType == null

private val Entity.isInlinedWithoutCid
    get() = dispositionType == "inline" && header.getField(FieldName.CONTENT_ID) == null

fun Entity.findTextBody(validMimeTypes: Set<String?>): TextBody? {
    // Added extension properties to the condition
    if (body is TextBody && mimeType in validMimeTypes && (isNotAttachment || isInlinedWithoutCid)) {
        return body as TextBody
    }

    if (!isMultipart) {
        return null
    }

    return (body as Multipart).bodyParts
        .firstNotNullOfOrNull { it.findTextBody(validMimeTypes) }
}
```

The `private` modifier is added to both functions because they should only be accessible from the Kotlin file where the `findTextBody` function is declared.

### Extracting the content

Let's add our new function to the extension properties we set up at the start.

```kotlin
val Message.text: String?
    get() {
        val textBody = findTextBody(setOf("text/plain", null)) ?: return null

        return TODO()
    }

val Message.html: String?
    get() {
        val textBody = findTextBody(setOf("text/html")) ?: return null

        return TODO()
    }
```

All that we have left now is to convert the `TextBody` into a `String`. We achieve this by writing the `TextBody` into a `ByteArrayOutputStream` and converting it to a `String` based on the `TextBody` charset. If the charset name is invalid, we will use the default charset (ASCII).

```kotlin
private val TextBody.content: String
    get() {
        val byteArrayOutputStream = ByteArrayOutputStream()

        writeTo(byteArrayOutputStream)

        return String(byteArrayOutputStream.toByteArray(), contentCharset)
    }

private val TextBody.contentCharset
    get() = try {
        Charset.forName(mimeCharset)
    } catch (e: IllegalCharsetNameException) {
        Charsets.DEFAULT_CHARSET
    } catch (e: IllegalArgumentException) {
        Charsets.DEFAULT_CHARSET
    } catch (e: UnsupportedCharsetException) {
        Charsets.DEFAULT_CHARSET
    }
```

### The final result

To finish our extension properties, we can access the `content` extension property of the `TextBody`.

```kotlin
val Message.text: String?
    get() {
        val textBody = findTextBody(setOf("text/plain", null)) ?: return null

        return textBody.content
    }

val Message.html: String?
    get() {
        val textBody = findTextBody(setOf("text/html")) ?: return null

        return textBody.content
    }
```

The implementation of our two new extension properties is now complete. We can use them as part of the `Message` interface.

```kotlin
fun main() {
    val textPart = BodyPartBuilder.create()
        .setBody("plain text content", "plain", Charsets.UTF_8)
    val htmlPart = BodyPartBuilder.create()
        .setBody("<html><body>content</body></html>", "html", Charsets.UTF_8)

    val multipart: Multipart = MultipartBuilder.create("alternative")
        .addBodyPart(textPart)
        .addBodyPart(htmlPart)
        .build()

    val message = Message.Builder.of()
        .setBody(multipart)
        .build()

    println(message.text) // -> plain text content
    println(message.html) // -> <html><body>content</body></html>
}
```

## Conclusion

Extensions in Kotlin are a powerful technique for implementing utility functions for third-party libraries. In this particular situation, they assisted us in reducing a 210-line Java class to approximately 50 lines of readable and maintainable Kotlin code*. If you want to see the entire code, check out this [Github gist](https://gist.github.com/spoptchev/e0821c4bf39032eb1f5f208f2f8fd8d8).

Here are a few general recommendations when you are getting started with Kotlin extensions:

* When you can put the properties or functions directly into the class or interface, don't use extensions.
* Expose the bare minimum set of functions or properties as extensions. Everything else should be kept private.
* Don't forget that extension functions are resolved statically. So, mocking them in a test is only possible when you use libraries like `PowerMock` or `MockK`.
* Another common pitfall is that extension functions are invoked based on expressions and not types. A good example can be found [here](https://kotlinlang.org/docs/extensions.html#extensions-are-resolved-statically).

Thank you for following me on this journey. Do you have any questions? Was this article helpful? Let me know in the comments below.

*) The Java code also includes logic for loading plain text and HTML depending on the multipart type (`alternative`, `related`, etc.). As a result, the comparison on the number of lines may not be fair in this case, but is still a pretty good indicator how Kotlin improves our development experience.