#Java

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!

[Read More]

With Kotlin 1.3, a new experimental feature called “Inline Classes” is now available. This post is a somewhat deep dive into the nature of the implementation, how it works, where the edges are, and what limitations currently exist. Let’s take a look!

[Read More]

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]

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.

[Read More]

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.

[Read More]

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.

[Read More]

One of Kotlin’s strengths is that generally speaking, the code you might write in Java is generally more compact in Kotlin without losing any of the readability, functionality, or performance.

An odd case where that doesn’t prove to be true is declaring loggers as Java developers.

[Read More]

This year at JVMLS, Brian Goetz talked about Pattern Matching on the JVM and how it might be modeled. In particular he spoke about:

• How Scala does it
• How C# does it
• How Java might do it
• How Java could do it with amortized constant-time Matching

[Read More]

Today’s Kotlin library article is about the kotlin.concurrent package, and everything that adds to the platform.

Java’s concurrency package is already quite sophisticated, and rather than re-invent so many extremely delicate abstractions, the Kotlin authors focused on making the libraries better suited to the language by decorating and shortening various features.

[Read More]

This is the second article in a series around Kotlin standard library additions. This article is all about the Kotlin comparator factory functions.

[Read More]