kotlin

You may know I’m a big fan of OpenTelemetry. I recently finished developing a master class for the YOW! conference at the end of the year. During development, I noticed massive differences in configuration and results across programming languages. Even worse, differences exist across frameworks inside the same programming language.

Pattern matching is a major feature in software development. While pattern matching applies in several locations, its current usage is limited to switch case blocks. I want to compare the power of pattern matching across a couple of programming languages I’m familiar with in this post. I assume that every reader is familiar with the switch case syntax inherited from C.

For the last two weeks, I’ve kicked the tires of OpenRewrite. At first, I created a recipe to move Kotlin source files as per the official recommendations with a set package name. I then improved the recipe to compute the root automatically. In both versions, I thoroughly tested the recipe. However, my testing approach was wrong. In this post, I want to describe my mistakes, and how I fixed them.

I started discovering OpenRewrite last week by writing a Kotlin recipe that moves Kotlin files according to the official directory structure recommendation. I mentioned some future works, and here they are. In this post, I want to describe how to compute the root package instead of letting the user set it.

I’ve been eying OpenRewrite for some time, but I haven’t had time to play with it yet. In case you never heard about OpenRewrite, OpenRewrite takes care of refactoring your codebase to newer language, framework, and paradigm versions. Using OpenRewrite is pretty straightforward. It already provides a large corpus of existing recipes, some of which are free. What I find amazingly powerful is the ability to author new recipes.

I’ve been eying OpenRewrite for some time, but I haven’t had time to play with it yet. In case you never heard about OpenRewrite, OpenRewrite takes care of refactoring your codebase to newer language, framework, and paradigm versions. OpenRewrite is an open-source automated refactoring ecosystem for source code, enabling developers to effectively eliminate technical debt within their repositories.

I’ve been eying OpenRewrite for some time, but I haven’t had time to play with it yet. In case you never heard about OpenRewrite, OpenRewrite takes care of refactoring your codebase to newer language, framework, and paradigm versions. OpenRewrite is an open-source automated refactoring ecosystem for source code, enabling developers to effectively eliminate technical debt within their repositories.

I recently compared three OpenTelemetry approaches on the JVM: Java Agent v1, v2, and Micrometer. I used Kotlin and coroutines without overthinking. I received interesting feedback on the usage of @WithSpan with coroutines: Nice one..by the way to instrument the coroutine context properly, don't we need "opentelemetry-extension-kotlin" also? Without that, spans are not recorded properly for suspend functions (https://t.co/DSgJklnllD) pic.twitter.

Displaying images on your website makes for an interesting problem: on one side, you want to make them publicly available; on the other, you want to protect them against undue use. The age-long method to achieve it is watermarking: A digital watermark is a kind of marker covertly embedded in a noise-tolerant signal such as audio, video or image data. It is typically used to identify ownership of the copyright of such signal.

Implicit returns are a feature in some languages. They have recently bitten me, so here’s my opinion. Statements, expressions, and returns Before diving into implicit returns, we must explain two programming concepts influencing them. A lot of literature is available on the subject, so I’ll paraphrase one of the existing definitions: An expression usually refers to a piece of code that can be evaluated to a value.

GitHub offers a way to customize one’s profile by allowing one to create a README in a specific repository, named as your profile, e.g., nfrankel/nfrankel. A couple of years ago, I automated the update of my GitHub profile with up-to-date info: my latest blog posts, my upcoming talks, and the last recorded YouTube talk. I took the time to document how to do it on this blog.

Last week, I was at the FOSDEM conference. FOSDEM is specific in that it has multiple rooms, each dedicated to a different theme and organized by a team. I had two talks: Practical Introduction to OpenTelemetry Tracing, in the Monitoring and Observability devroomWhat I miss in Java, the perspective of a Kotlin developer, in the Friends of OpenJDK devroom The second talk is from an earlier post.

Java has been my bread and butter for almost two decades. Several years ago, I started to learn Kotlin; I never regretted it. Though Kotlin compiles to JVM bytecode, I sometimes have to write Java again. Every time I do, I cannot stop pondering why my code doesn’t look as nice as in Kotlin. I miss some features that would improve my code’s readability, expressiveness, and maintainability. This post is not meant to bash Java but to list some features I’d like to find in Java.

A couple of years ago, I developed an application in Kotlin based on Camunda BPMN to help me manage my conference submission workflow. It tracks my submissions in Trello and synchronizes them on Google Calendar and in a Google Sheet. Google Calendar offers a REST API. As REST APIs go, it’s cluttered with String everywhere. Here’s an excerpt of the code: fun execute(color: String, availability: String) { findCalendarEntry(client, google, execution.conference)?.let { it.

Scala has popularized the 'Pimp my library' pattern: This is just a fancy expression to refer to the ability to supplement a library using implicit conversions. — Pimp My Library Pattern in Scala Kotlin does provide the same capability. However, it achieves it via extension functions. While the generated bytecode is similar to Java’s static methods, the developer experience is the same as adding functions to existing types. This approach has limitations, though.

Some time ago, I read a post describing how to run a serverless Kotlin function on OpenFaaS. While the content is technically correct, I believe the concept itself is very wrong. Such posts can lead people to make ill-advised decisions: 'because we can' is hardly a winning strategy. in this post, I’d like to first explain why the JVM platform is a bad idea for FaaS. Then, I’ll proceed to propose alternatives to use Kotlin nonetheless.

Two weeks ago, I wrote how you could write a Spring application with no annotations. Many alternatives are available to configure your Spring app. I’d like to list them in this post, leaving Spring Boot out of the picture on purpose. Core concepts Property file XML Groovy DSL Self-annotated classes Configuration classes Kotlin DSL Bean definitions Beans Conclusion Core concepts A couple of concepts are central in Spring.

This is the 5th post in the The state of JVM desktop frameworks focus series. The previous posts of this series were dedicated to frameworks that were pretty similar to each other. This week’s post is dedicated to Jet Compose for Desktop, the new kid on the block that offers an original approach.

This is the 4th post in the The state of JVM desktop frameworks focus series. The two previous posts of this series were respectively dedicated to Swing and SWT. This post is dedicated to Tornado FX, which itself is built on JavaFX.

This is the 3rd post in the The state of JVM desktop frameworks focus series. This series is dedicated to the state of JVM desktop frameworks. After having had a look at Swing the previous week, this post focuses on the Standard Widget Toolkit. SWT originates from the Eclipse project, an IDE. For Eclipse, the developers built a dedicated framework to build their graphic components upon. Swing implements the drawing of widgets in Java from scratch.

This is the 2nd post in the The state of JVM desktop frameworks focus series. In the first post of this series, we went through the rise and fall of some of the desktop frameworks, mainly Java ones. This post and the following will each focus on a single JVM framework. To compare between them, a baseline is in order. Thus, we will develop the same application using different frameworks.

Last September, I wrote how to migrate from an Imperative Programming codebase to a Reactive Programming one in a step-by-step process. Because of its popularity, I illustrated the post with a Spring Boot demo. The final result uses Mono and Flux from Project Reactor. I also made sure that no step in the processing pipeline is blocking thanks to Blockhound. I wrote the code in Java so that it could be accessible to the largest audience. But I’m still a Kotlin fan at heart.

Recently, GitHub allowed users to customize the appearance of their profile page. This is different from GitHub Pages: it allows to add extra content to one’s GitHub profile. Since that feature is available, a lot of developers have decided to customize their page. I think this is fun, so I also wanted to do the same, in my own way. I wanted to describe it, so fellow developers can take inspiration. Since the whole process is a bit long, I’ve split this post in two parts.

Java is the first language that I learned and used professionally. It has been my bread and butter for about a decade and half years. And yet, it’s not the only language I’ve learned nor used in all my years: for example, a long time ago, I’ve had to develop JavaScript code to implement a dynamic user interface. At that time, it was called DHTML…​ A couple of years ago, I also taught myself Kotlin, and never stopped using it.

A recent question on Kotlin’s Reddit came to my attention lately: 'Why is it bad to write extension functions for classes that you own?' One of the answer was that it was the opposite: it’s a good practice, and for several reasons. Among them were two very important ones that improve the design of one’s code: Able to call the function on a nullable. For a class with generic types, add a function that is only available when a specific type is used.

Consider 2 types X and Y, and a function f defined as: class X, class Y and val f = { _:X → Y() }. In Kotlin, it’s possible to call the function f with a parameter of type X using invoke(): fun f(x: X) = Y() val y: Y = f.invoke(X()). The following calls the function f with a parameter of type X using invoke().

A derived attribute is an attribute computed from other attributes e.g.: The fullName is aggregated from the first, middle and last nameThe age is computed from the birthdateetc. Kotlin offers different options to manage such derived attributes. Let’s browse through them.

Recently, I stumbled upon a Reddit thread pointing to a repository comparing the performances of implementations of the Sieve of Eratosthenes in different languages. The results were, let’s say, intriguing. The worst surprise came from Kotlin. I couldn’t believe my eyes! Then, I looked at the code.

When streams were added to Java 8, I wanted to jump on the bandwagon. I read blog posts, watched videos, attended workshops to understand what this was all about. After a while, I became comfortable enough…​ but I was unhappy with the implementation: while streams offer methods with a functional approach, legacy collections do not. When one wants to use Java capabilities on an existing collection, the later needs to be transformed to a stream, and then back again.

I’m not a regular StackOverflow user, neither as a contributor, nor to ask questions. However, I recently stumbled upon a question, tried to help…​ and failed. I was pointed out my answer was wrong - thanks for everyone who did. I think failures are great occasions to learn something new! In this post, I’d like to detail what I learned after digging further: there are several ways to combine elements from an existing collection in Kotlin stdlib.

Last week, I read a post about Kotlin code analysis, thanks to the Kyiv Kotlin UG. I stumble upon a lot of similar posts: they show how to hack into the build to produce a text report showing quality issues. At the risk of sounding arrogant, I claim this is not proper software engineering. It’s a one-time hack: it has no value over the long term. Code quality is a serious subject, and should be treated accordingly.

This week, I’d like to tackle an interesting approach that is quite useful. Design by contract prescribes that developers should define preconditions, postconditions and invariants. These specifications are referred to as 'contracts'.

Since I discovered Kotlin, I use it in all my personal projects. I’ve become quite fond of the language, and with good reason. However, there’s yet no integration with the Hybris platform - though there’s with Groovy and Scala. This post aims at achieving just that, to be able to use Kotlin on Hybris projects. Generate a new extension The first step on the journey is to create a new extension: ant extgen Choose the yempty packageChoose an adequate name, e.g.

IMHO, Kotlin is not about big killer features - although extension methods and properties could certainly be categorized as such, but about a bunch of small improvements that have deep impact. Most of them are not built-in into the language, but are functions offered as part of the Kotlin standard library. In this post, I’d like to go through a limited set of them, and describe how they can be used to improve the code.

There is a bunch of languages running on the JVM, from of course Java, to Clojure and JRuby. All of them have different syntaxes, but it’s awesome they all compile to the same bytecode. The JVM unites them all. Of course, it’s biased toward Java, but even in Java, there is some magic happening in the bytecode. The most well-known trick comes from the following code: public class Foo { static class Bar { private Bar() {} } public static void main(String...

Every now and then, there’s an angry post or comment bitching about how the Spring framework is full of XML, how terrible and verbose it is, and how the author would never use it because of that. Of course, that is completely crap. First, when Spring was created, XML was pretty hot. J2EE deployment descriptors (yes, that was the name at the time) was XML-based. Anyway, it’s 2017 folks, and there are multiple ways to skin a cat.

Every now and then, there’s a post predicting the death of the Java language. The funny thing is that none of them writes about a date. But to be honest, they are all probably true. This is the fate of every language: to disappear into oblivion - or more precisely to be used less and less for new projects.

This is the 4th post in the Scala vs. Kotlin focus series. Inheritance is one of the basic tenet of Object-Oriented Programming, along with encapsulation and polymorphism. Alongside simple inheritance, there is multiple inheritance: feature of some object-oriented computer programming languages in which an object or class can inherit characteristics and features from more than one parent object or parent class.

This is the 3rd post in a series about creating a SonarQube plugin for the Kotlin language: The first post was about creating the parsing code itself.The 2nd post detailed how to use the parsing code to check for two rules. In this final post, we will be creating the plugin proper using the code of the 2 previous posts.

Last week, we used ANTLR to generate a library to be able to analyze Kotlin code. It’s time to use the generated API to check for specific patterns. API overview Let’s start by having a look at the generated API: KotlinLexer: Executes lexical analysis.KotlinParser: Wraps classes representing all Kotlin tokens, and handles parsing errors.KotlinParserVisitor: Contract for implementing the Visitor pattern on Kotlin code.

Since I started my journey into Kotlin, I wanted to use the same libraries and tools I use in Java. For libraries - Spring Boot, Mockito, etc., it’s straightforward as Kotlin is 100% interoperable with Java. For tools, well, it depends. For example, Jenkins works flawlessly, while SonarQube lacks a dedicated plugin. The SonarSource team has limited resources: Kotlin, though on the rise - and even more so since Google I/O 17, is not in their pipe.

A long time ago, one had to manually start new threads when wanting to run code concurrently in Java. Not only was this hard to write, it was easy to introduce bugs that were hard to find. Testing, reading and maintaining such code was no walk in the park either. Since that time - and with a little incentive coming from multi-core machines, the Java API has evolved to make developing concurrent code easier.

I assume that readers are already familiar with the Kotlin language. Advertised from the site: Statically typed programming language for the JVM, Android and the browser 100% interoperable with Java™ — Headline from the Kotlin website Kotlin first penetrated the Android ecosystem and has seen a huge adoption there. There’s also a growing trend on the JVM, via Spring Boot. Since its latest 1.1 release, Kotlin also offers a production-grade Kotlin to JavaScript transpiler.

UPDATED on March 13, 2017: Add Builder pattern section Most developers have strong opinions regarding whether a language should be strongly-typed or weakly-typed, whatever notions they put behind those terms. Some also actively practice stringly-typed programming - mostly without even being aware of it. It happens when most of attributes and parameters of a codebase are String.

Though Kotlin and Spring Boot play well together, there are some friction areas between the two. IMHO, chief among them is the fact that Kotlin classes and methods are final by default. The Kotlin docs cite the following reason: The open annotation on a class is the opposite of Java’s final: it allows others to inherit from this class.

Microservices are not a trend anymore. Like it or not, they are here to stay. Yet, there’s a huge gap before embracing the microservice architecture and implementing them right. As a reminder, one might first want to check the many fallacies of distributed computed. Among all requirements necessary to overcome them is the ability to follow one HTTP request along microservices involved in a specific business scenario - for monitoring and debugging purpose.

This is the 2nd post in the Scala vs. Kotlin focus series. Last week, I started my comparison of Scala and Kotlin with the Pimp my library pattern. In the second part of this serie, I’d like to address operator overloading.

I know about Lombok since a long time, and I even wrote on how to create a new (at the time) @Delegate annotation. Despite this and even though I think it’s a great library, I’ve never used it in my projects. The reason for this mostly because I consider setting up the Lombok agent across various IDEs and build tools too complex for my own taste in standard development teams.

Logging is a not a sexy subject but it’s important nonetheless. In the Java world, logging frameworks range from Log4J to SLF4J via Commons Logging and JDK logging (let’s exclude Log4J 2 for the time being). Though different in architecture and features, all of their API look the same. The logger has a method for each log level e.g.: debug(String message)info(String message)error(String message)etc. Levels are organized into a hierarchy.

A little more than 2 years ago, I wrote a post on how you could create a Die rolling API in Scala. As I’m more and more interested in Kotlin, let’s do that in Kotlin. At the root of the hierarchy lies the Rollable interface

This week, I tried to improve my pet Android application developed in Kotlin. As I was very new to Kotlin when I started it, most of the code just looks like Java written in Kotlin. I will start simply.

Since about a year and a half, I do a lot of presentations on Mutation Testing. In those, my point is to show that Code Coverage’s only benefit is that it’s easy to compute but that it’s meaningless - hence Mutation Testing. Since some time, I’ve been interested in Kotlin, a language from JetBrains that runs on the JVM. It’s only natural that I wanted to check how Mutation Testing could be applied to the Kotlin language.

I recently stumbled upon a post telling about the Josephus problem and trying to solve it in different scripting languages. For the sake of brevity, here’s the problem (taken from the referenced post): Flavius Josephus was a roman historian of Jewish origin. During the Jewish-Roman wars of the first century AD, he was in a cave with fellow soldiers, 40 men in all, surrounded by enemy Roman troops. They decided to commit suicide by standing in a ring and counting off each third man.

It’s no mystery that I’m a fan of both Spring Boot and Vaadin. When the Spring Boot Vaadin add-on became GA, I was ecstatic. Lately, I became interested in Kotlin, a JVM-based language offered by JetBrains. Thus, I wanted to check how I could develop a small Spring Boot Vaadin demo app in Kotlin - and learn something in the process. Here are my discoveries, in no particular order.

There’s not one week passing without stumbling upon a post claiming language X is superior to all others, and offers you things you cannot do in other languages, even make your kitchenware shine brightier and sometimes even return lost love. I wouldn’t mind these claims, because some features really open my Java developer mind to the lacking of what I’m using now, but in general, they are just bashing another language - usually Java.