When learning a language built on another existing platform, like TypeScript (or, for that matter Kotlin), one of the challenges you face is understanding the underlying platform or language so that you can, in turn, understand how the higher-level language is applied to meet the restrictions and features of the lower-level language.

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.

Recently, I was driving my 2015 Jeep Wrangler JK Unlimited through a parking lot on a 95 degree day, and after leaving a stop sign, a check engine light flashed on (later I would learn it was a P0480 Cooling Fan Relay 1 Control Circuit), and shortly thereafter my Jeep overheated. What followed was a multi-day Google searching and diagnostic session, which made me realize there is a lack of information as well as a lot of mis-information about the 3.6L “Pentastar” Jeep Wrangler model years, and how the radiator fan works.

This is my summary of what I learned about the cooling fans on these Jeeps, so hopefully more people can diagnose issues themselves.

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.

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.