## Values, Records, and Primitives (Oh My!) - Kotlin & Java's 'Valuable' Future

A couple years ago, I did a semi-deep-dive on Kotlin Inline Classes and how they were implemented. Kotlin 1.5 was just released, and with it came the evolution of inline classes into the start of value classes. Meanwhile, Kotlin 1.5 also now supports JVM Records, which at first read might sound like a very similar concept. Finally, with JEP-401 Java is going to bring “primitive classes” which also sounds like a very similar concept. This can sound all very confusing, so let’s take a look!

## Paperless Adulting on Linux with Evernote and NoteSlurp

Adulting is hard. Bills come and go, taxes have to be prepared, escrows have shortages, kids have activites, FSAs need proof of medical expenses, cars need to be registered.

The list of things an adult has to do seems to only grow larger over time, and one of the fundamental things that all adults seem to have to do is to track and file paperwork. I’ve gone “paperless” in my personal life (which I seem to have interpreted it to mean: “keep digital copies of everything, even if it was paper originally”).

When it comes to adulting, barriers to doing the right thing (like actually getting stuff filed paperlessly) are bad, as you won’t do them. So, recently I decided to make that just a little bit easier on myself with a new tool. Let me walk through the research I’ve done, what my process for paperless filing is, and where I’ve historically had problems, and how this new tool has helped me out.

## Unsigned Integers with Java and Kotlin 1.3

Something that has always been a bit of a limitation in the Java numeric type system is the lack of support for unsigned integers. It is not particularly common to have to work with unsigned types, but when it does happen, it’s usually unpleasant in some way. Libraries like Guava have provided utilities to make it cleaner, and recent updates to Java 8 also included some unsigned helper methods.

Kotlin 1.3 has an experimental feature to make unsigned types a full citizen of the type system, while still having all of the performance of primitive integer types. Let’s take a look!

## Contracts in Kotlin 1.3

Kotlin 1.3 is bringing a new experimental feature to the compiler to help with improving program correctness via the type-system: contracts.

Contracts are a tool that allow library code (both standard library and your libraries) hint to the compiler about the constraints that are ensured on types based on the use of functions in your program. Let’s see how this can be used in practice.

## De-Structuring in Kotlin

Recently I wrote an article about de-structuring in TypeScript, and hinted that Kotlin has a similar feature, but in more of a “strongly typed” language style. Today I want to discuss that feature. To re-cap from the previous article, de-structuring is, at the core, a syntactic sugar to easily “lift” parameters out of an object or array and declare local all in one shot. With ECMAScript and TypeScript, this comes in two forms: positional (for arrays and iterables) and by name (for objects). [Read More]

## What's the Deal with @JvmDefault?

Kotlin has an annotation called @JvmDefault which, like most of the “Jvm” prefixed annotations, exists to help massage the Kotlin compiler output to match Java classes in a certain way. This annotation was added in 1.2.40, and has now seen some experimental enhancements in 1.2.50, so it seems worth exploring what this is all about.

## Tail Recursion in Kotlin

Tail recursion can be a very elegant way to solve problems that involve a significant number of iterations but are better organized using recursion, without paying the cost you normally pay for recursion. Kotlin can enable the use of tail recursion. To understand the benefits of this, a quick recap would be of value.

## Kotlin: Reified Type Function Parameters

As most Java programmers know, Java generics are erased at compile-time. This has trade-offs, but the two main reasons for this are:

• Compatibility - Java 1.4 and earlier dealt exclusively in raw types at the VM level. Generics were able to compile without introducing significant new typing to the bytecode and classfile format spec, and having to deal with older classes generated without that typing.
• Simplicity - By erasing to raw types, the JVM doesn’t have to understand specialization; something that has its own complexities and downsides. For example, specialized types are much more challenging to optimize with a just-in-time compiler.

However, knowing the type parameters used at runtime can have real value, and it’s something Java simply doesn’t offer. Kotlin would like to help in this area, but there are many challenges in doing so.