In my humble opinion, IntelliJ is the best Java IDE out there. But even the best IDE can be improved. In this blog I will tell you why I decided to create a plugin and how this went down.

Let’s backtrack a few steps to understand why I decided to write a plugin. I was preparing to give a talk at Devoxx France. It is a live coding session that shows off features of the debugger. Every time when I prepare to give a talk, I try to update the talk. This time I decided to use the new UI of IntelliJ. No sooner said than done I applied the change and started practicing. During the first test run I noticed that there was a bug in the new UI. In the old UI I could shift click in the gutter to get a logging breakpoint. This did not work in the new UI. Furthermore I was looking for a solution to get a logging breakpoint without the use of the mouse. I was not able to find a solution for this problem. Therefore I decided to kill two birds with one stone. I decided to create a plugin that solves both problems.

So my first thought was to just create a plugin, because how difficult can that be? Those were famous last words, because it turned out to be much harder than I expected. My initial idea was to create a “proper” plugin. That is a plugin that can easily be installed by others by downloading it from the Jetbrains Marketplace. Within an hour it was clear that creating a proper plugin is hard and takes a lot of time. Luckily IntelliJ offers a simpler solution in the form of a live plugin. You can directly test your plugin in the IDE without complicated steps. This plugin does not end up in the marketplace, but is far simpler to develop. Far simpler does not mean it is simple. It still took several evenings to get it to work properly.

So the goal is to create a live plugin that will create a logging breakpoint without using the mouse. The latter part is easily solved by binding the action of the plugin to a keyboard shortcut. Creating a logging breakpoint in code is a bit harder, but before we dive into that let’s explain what a logging breakpoint is and how you create one manually. A logging breakpoint is a breakpoint that only logs something and does not suspend. Both these breakpoint options (logging and non-suspending) are relatively unknown. But you can easily create a logging breakpoint by first creating a simple line breakpoint and then changing its properties. You have to make the breakpoint non-suspending (so it should not pause the execution of your program) and it should have a logging expression. The screenshot below shows how this would look like in IntelliJ.

Picture 1 - A logging breakpoint in IntelliJ

So doing it manually is pretty straightforward and now it is time to do this with a live plugin. The first step is to install the live-plugin plugin from the marketplace. This enables the live plugin functionality. The second step is to write the live plugin itself. You can choose between Groovy or Kotlin when creating one. I decided to go with the latter, because I am more familiar with that language. 

After looking at some example plugins I decided it was time to start writing my own. I broke the problem down in the following sub-problems:

show a notification when pressing a keyboard shortcut

set a simple breakpoint when pressing the shortcut

modify the breakpoint so it becomes a logging breakpoint

use the current selection to determine what to log

Let’s start with the first, showing a notification when pressing a keyboard shortcut. I copied an existing plugin from a tutorial that did exactly this and started modifying it. The only modification that it needed was changing the keyboard shortcut. This was relatively easy and within fifteen minutes I had this sub-problem solved. On to the next one!

The goal here is to set a simple breakpoint when pressing the right key combination. My plugin already reacted to the correct key combination, so I only have to create a breakpoint. This is where it became pretty complicated. I had no clue which API to use. So I spend several hours browsing through the IntelliJ API documentation to get a vague direction. Then I browsed a lot of classes in the com.intellij.xdebugger package to find the first glimmers of hope. I found the class XDebuggerUtilImpl and it had a method called toggleAndReturnLineBreakpoint. This seems like the right place to start! Unfortunately the method took six parameters. I will not bore you with all the details, but let’s focus on one. The method needs a list of breakpoint types. This sounds logical, because it needs to know the possible types of breakpoints it can set. But the type of parameter looks like this: List<XLineBreakpointType<P extends XBreakpointProperties> extends XBreakpointType<XLineBreakpoint<P>, P>>. Okay, this is not for the faint of heart. Several hours later I got the hang of it and I was able to create a simple breakpoint by pressing the right keyboard shortcut. Hooray!

The next step is to modify this breakpoint so it will not suspend the execution of the program and it will log something. This part was pretty straightforward. The methods mentioned above returned a promise with a breakpoint in there. After using two simple setters the simple breakpoint became a logging breakpoint. The sweet smell of victory is almost mine!

Next up is using the current selection to determine what will be logged. The idea is that the user selects a variable and the breakpoint will log the name and the value of the variable. It should also work when selecting an expression. In that case it will print the expression and its outcome. It is pretty simple to get the selected text and to use this to create the desired logline. Only one subproblem remaining!

The last one is putting the breakpoint on the next line. This needs a little bit of explaining, because initially I thought that putting the breakpoint on the same line would be fine. It turns out that this does not work well when creating a variable. When you set a breakpoint it will pause the execution at the beginning of the line, so before it creates the variable. If the variable does not exist yet, it is impossible to read and log its value. Therefore I decided to put the breakpoint on the next line. This turned out to be too simplistic, because the next line could be a whiteline and those do not support breakpoints. The final solution is to put the breakpoint on the next line that supports breakpoints. I learned a lot about caret models, cursor offsets and source positions, but several hours later I had a working prototype!

So with this plugin I do not need to use the mouse when creating a logging breakpoint. Furthermore I can quickly create logging breakpoints while using the new UI. Just selecting a variable and pressing the right keys on the board is enough.

The final result can be found on Github: https://github.com/BoukeNijhuis/devoxxfr2023/blob/main/.live-plugins/plugin.kts. The file plugin.kts is in the .live-plugins folder so the live-plugin plugin will automatically load the plugin whenever the project is opened in IntelliJ.

So after some evenings of writing a live plugin it is time to create a “proper” plugin which can be easily installed from the JetBrains marketplace. But this is a story for another time. Once this time arrives I will write another blog about it.

How to write an IntelliJ plugin that creates a logging breakpoint without a single click.

How to write a simple IntelliJ plugin

Recently I had to do something that wasn’t exactly in my wheelhouse. It also was kind of a one-off thing. I had to provide an initial load. In this case it meant that I would receive a huge csv file and somehow had to turn it into one big XML file. And if that wasn’t bad enough… They needed the XML file yesterday!  After a quick Google search there it was… Spring Batch! Initially I thought this is overkill for a one-off type of thing. But nevertheless I decided to give it a shot. And guess what? Within a few hours I had cooked up a pretty good solution. So not bad at all!  In this blog I am going to show you how easy it is to build a Spring Batch component (backed up by Spring Boot) that will transform a csv file into an XML file.

The objective sounds simple. I have a csv file which could look something like this:

711 Ocean Drive;Joseph M. Newman;Crime drama;Columbia
Abbott and Costello in the Foreign Legion;Charles Lamont;Comedy;Universal

and somehow I have to turn this csv file into this:

<?xml version="1.0" encoding="UTF-8"?>
<Movies>
   <Movie>
       <Title>711 Ocean Drive</Title>
       <Director>Joseph M. Newman</Director>
       <Genre>Crime drama</Genre>
       <Remark>Columbia</Remark>
   </Movie>
   <Movie>
       <Title>Abbott and Costello in the Foreign Legion</Title>
       <Director>Charles Lamont</Director>
       <Genre>Comedy</Genre>
       <Remark>Universal</Remark>
   </Movie>
</Movies> 

Spring Batch to the rescue! To make this work the Spring Batch application needs these things:

some configuration to glue it all together (Job Launcher, Job Repository, Job & Step)


But first we have to import some Maven dependencies.

  <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-batch</artifactId>
   </dependency>

   <dependency>
       <groupId>org.hsqldb</groupId>
       <artifactId>hsqldb</artifactId>
       <version>${h2.version}</version>
       <scope>runtime</scope>
   </dependency>

The most important dependencies are the spring-boot-starter-batch for our out of the box batch functionality and the hsqldb for storing all the job information and other non-interesting stuff that Spring needs to execute the job. 

For the full list of dependencies I suggest checking out the project from my GitHub. You can find the link to my project at the end of this blog.  

First up is the configuration. We create a configuration class and enable the batch mechanism by using the @EnableBatchProcessing annotation. This is an important little thing to do because if you don’t place the annotation on top of that class the whole thing will not work!

In this configuration class we define the input file (our csv) and output file (the XML). Also we have to inject the JobBuilderFactory and StepBuilderFactory. We are going to use these factories later on to configure our job. 

The next thing we need to do is create the Item Reader. The Reader will, as you might have guessed already, read the csv file and store the records for further processing. For storing we need to have a DTO (Data Transfer Object) so we will first create that one. Processing is on a per record basis, so we just need to model the record only (not the whole csv). 

Nothing fancy, nothing exciting… just a DTO.

Now it’s time to implement the reader. This will be a bean in the SpringBootBatchConfig class. It goes too far to put all the code in here so I suggest checking out the code from my GitHub and see what it exactly does and what it is made of but here is the snippet for my ItemReader.

Two things to note. This reader needs the input csv file so we have to set the Resource and it also needs a mapper for mapping the csv data to the Movie DTO.

Creating the mapper is as easy as implementing the Spring Batch FieldSetMapper interface and mapping the fields of the csv into the DTO.

We can simply read each field in the csv by using the readString method which accepts the index of the field you want. readString(0) for reading the first field of the record, readString(1) for the second field and so on.

Reader… Implemented! Next up is the Item processor. The processor will execute for each record in our csv. ItemProcessor is a Spring Batch interface. All the processor really does is accept an object from the ItemReader and pass it on to the ItemWriter. 

We only need to implement the processing logic which is basically mapping the Movie DTO (which was used during reading) to another DTO which represents the XML “record” (or XML node to be more precise). 

The XmlMovieDTO is annotated with @XmlRootElement to define the name of the movie node that will be used in the XML file. Because we annotate the fields with @XmlElement (and not the getters) we also have to annotate the class with @XmlAccessorType(XmlAccessType.FIELD). If you don’t do that then your application will complain that it has two properties of the same name and you are treated to several IllegalAnnotation exceptions! 

And that’s it for the processor. Movie in… XmlMovie out. 

Almost there. We just need to implement the writer and do some configuration and we are done. But first things first. Let’s implement the writer. The writer is also implemented as a bean in the SpringBootBatchConfig class.

Here we have to create a StaxEventWriter, which is an XML writer. It needs a marshaller for converting the XmlMovieDTO object into actual XML, a root tag name for the root element/node of the XML and the location (Resource) where the XML output file is going to be placed.   

To tie all of the components together and make it work we have to configure a job. A job can have several steps. In our case we just need one step in the job. 

When you look at the step method you see that this is the place where it all comes together. The reader, the processor and the writer. And that is all! Just run the application and your csv file will be turned into an XML file in no time. 

Did you notice that I didn’t even talk about the Job Repository and the Job Launcher that were shown in the overview picture? That’s because I don’t have to. Spring Batch takes care of all the low-level boring stuff and you can focus on the actual business logic.

The full working example can be found on my GitHub: 

https://github.com/vlouisa/spring-batch-demo/tree/master

As a bonus I added a version of the application that can transform the same input file into files with a different output format (JSON & XML). Switching between formats is handled in the application.properties file. Just set the correct profile and there you go!

The multiple output format version can be found over here:

https://github.com/vlouisa/spring-batch-demo/tree/multiple-output-format

How to use Spring Batch to process a .csv file to XML.

Spring Batch CSV to XML

Spring Batch to the rescue

As a front-end developer, I work with a lot of tools to develop code. There are a few popular tools that I use and recommend for programming better front-end applications. Also, I would like to describe what I do to manage applications and how to simplify the process. It can be a really difficult process when you are building a bigger front-end application. I will explain the tooling that I use in this article.

Find and fix problems in your JavaScript code

The first recommended tool is ESLint. Most of the newest JavaScript applications are using Typescript. With the combination of ESLint and Typescript, the code quality will improve. When you are using this tool, it is possible to enforce standards for your team, but also for yourself. On the other hand, it helps you to think about your code and will help you when you forget something. For example, if you forget a type definition for one of your methods.

You can start with ESLint by installing it via npm. After installing ESlint you will find a configuration file in the root of your folder directory called eslintrc.json. The recommended way is to use a config like this:

"extends": [
  "eslint:recommended",
  "plugin:prettier/recommended",
  "plugin:@typescript-eslint/recommended"
],

I do not like to have a lot of custom configuration. This helps to prevent discussion within the team about specific rules. There are some rules that I do recommend. One of these is a simple rule to give an error for unused imports. To enable this rule, you will need a plugin.

In your rule configuration can you define what you should do in case of unused imports.

"@typescript-eslint/no-unused-vars": ["error"],
"unused-imports/no-unused-imports": "error",

In addition to these rules, I have a few other rules. I always want to give a type definition for a return function and do not allow the use of the any type. You can read the complete documentation of ESlint on the website.

An example eslint configuration can be found here.

One of the biggest frustrations, when I start at an existing project, is having no code standards. You want to talk about the function of the new code when somebody has opened a pull request and not about its formatting. That is why code standards are important. Of course, both are important, but formatting should be consistent across files. That is pretty hard when you do not have rules or principles. We cannot automate everything, but some tools can help us. One of these tools is Prettier.

Prettier is a tool that you can use in your codebase to format your code. It supports a lot of programming languages. You do not need to discuss style in your code review and this will save you time and energy. After you install it with npm, you also have a simple configuration file called prettierrc.json. I use a configuration like this:

In the above example, you can see a few options. I want to use a maximum of 140 characters per line, not use double quotes, and format with spaces instead of tabs. The complete list of the Prettier options can be found on their website.

An example Prettier configuration can be found here.

Automate your code standards before you commit

The next step would be automating the tools above. I prefer to do two different things. The first one for Prettier is to implement an auto-save functionality for your code editor. For example in Visual Studio Code, you can create a settings.json in a .vscode folder at the root of your codebase. You can set a default formatter and a format on save boolean for the whole project. The default formatter below can be installed as a plugin.

"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,

The other step is to implement a pre-commit hook before you commit definitively to your repository. I use the tool Husky for that part. Husky is a tool to lint your commit messages, run tests, and in my case run the lint rules above. Also, it is possible to combine those. I often use it for linting code and running unit tests.

You can install Husky via an automatic command. It will give you everything you need for your first pre-commit hook, including an example to run your test. You can also install Husky manually. The steps to do this can be found here. After installing you will find a .husky folder in the root of your codebase. Inside this folder, you will find the commit hooks that are used. 

The latest step to prevent adding bad code in your codebase is to use the tool lint-staged. With this tool, it is possible to run linters over staged git files. By using this tool you can have control before you push code into the repository. To use lint-staged you need to install it via npm. After that part, you can configure which files are checked while using the lint-staged command. You can do this via a lint-staged part in your package.json or via .lintstagedrc.json file in the root of your directory. The recommended way is to use a config like this:

{
  "*.{ts,tsx,html}": "eslint --cache --fix",
  "*.{ts,tsx,html,scss}": "prettier --write"
}

The example above also includes a fix flag for eslint and a write flag for prettier. During the pre-commit phase, files are changed automatically when possible. To use lint-staged in your pre-commit hook, add a file like this:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
 
npx lint-staged
npm run lint

It does not always stop everything, but it does help. To get control over your application, I can recommend running linters and tests to your pipeline. In that case, you know for sure that your code has been checked.

An example Lint-Staged / Husky configuration can be found here.

It can be difficult to produce quality code when the business is waiting for new functionality. To improve code quality, I use SonarQube. This tool helps you to find bugs, code smells, vulnerabilities, and duplications. It is available in a lot of languages including JavaScript, TypeScript, HTML, and CSS. For brevity, I will not explain how you should install SonarQube in this article, but I hope you see the added value.

SonarQube does scan your static code. For me, the greatest benefit is the simplicity of the code, which helps to better understand other developers' code and make fewer mistakes in the code. After the scan, you see metrics of complexity, vulnerabilities, and duplications. This information increases your productivity, maintainability, and consistency. I believe that this can help you to increase the lifetime of the application. In addition, it will help to improve your developer skills.

Each front-end application consists of a lot of packages. These are included in the package.json with a specific version. It is important to update these packages regularly. If you do not, you get a big bang upgrade scenario which takes a lot of time, or more importantly, you could get security issues. Furthermore, your application can be outdated for specific devices. It can make future development hard when you postpone this.

Like using hooks you can use a bot to update these packages. Renovate is one of these bots which you can use for automated dependencies updates. It scans your dependency tree for old versions and updates them via a pull request. First, you should connect Renovate to your repository, so it has permission to read your codebase. Then you can create a renovate.json in the root of your directory. There are some configurations that I can recommend to use. One of these is to auto-merge for a minor or patch update.

“packageRules”: [
  {
      “matchUpdateTypes”: [
      “minor”,
      “patch”
    ],
    “automerge”: true
  },
]

By default, Renovate will create a PR for every package that can be updated. There is a rule to group packages so that we get fewer pull requests. You can create groups based on a pattern. With this can you bundle packages. In the example below I created a group for eslint. This combines updates for eslint and @next/eslint to a single pull request.

{
    “matchPackagePatterns”: [
    “^eslint”,
    “^@next/eslint”
  ],
  “groupName”: “eslint”
},

There are many more options to configure. For instance, when Renovate should run and how many pull requests are allowed to be open at the same time. Auto merge is useful if you have a good CI/CD pipeline with linters, tests, and finally deployment. The complete documentation can be found on the website.

An example Renovate configuration can be found here.

A great part of this article goes about consistency and automation. The code must be clear for other developers and yourself. The lifetime of your application will be longer when you have good maintainability. A few simple tools and configurations can make the code a lot better. Why not use it? It will not get any worse.

I am working hard for code consistency. In my experience, I want to discuss what the code should do and do not like to talk about personal preferences of coding standards. By automating and maintaining you avoid the discussion. Hopefully, this article is helpful for your challenges with developing front-end applications.

Which tools do I use for improving front-end applications?

Deze presentatie gaat over het verbeteren van je debugging game. De meeste ontwikkelaars gebruiken alleen het spreekwoordelijke topje van de ijsberg bij het werken met de debugger. Er valt nog zoveel meer te leren, dus laten we eens kijken naar interessante mechanismen zoals:

frames laten vallen ("teruggaan in de tijd")

foutopsporing op afstand (waarom op uw lokale computer blijven?)

hot code swapping (sneller dan het opnieuw implementeren van de code)

stream debugging (voor die moeilijk te debuggen streams)

De hele presentatie zal in IntelliJ zijn. Sommige delen zijn specifiek voor IntelliJ, maar de meeste delen zijn van toepassing op alle IDE's.

Improving your skills with the debugger by Bouke Nijhuis

Bouke Nijhuis
Bouke Nijhuis is CTO bij CINQ ICT. Hij vindt het leuk om nieuwe dingen te leren en hij vindt het nog leuker om die aan andere mensen uit te leggen. Verder is hij een internationaal spreker en een committer van open source projecten. Je kunt hem bereiken op Twitter via @BoukeNijhuis.

Bouke Nijhuis op Devoxx 2022 - Improving your skills with the debugger

Sinds ongeveer een jaar werk ik met Kotlin, een taal die ik persoonlijk zie als de spirituele opvolger van Java. Het wordt ontwikkeld door JetBrains, de ontwikkelaars van de populaire editor IntelliJ, en heeft een hoop voordelen ten opzichte van Java. Deze voordelen zijn ook niet dusdanig obscuur dat ze niet opvallen - ik gebruik ze bijna dagelijks. In deze blogpost wil ik een blik werpen op welke onderdelen van Kotlin mij helpen, en in sommige gevallen hoe ze zich verhouden tot Java.

Het belangrijkste voordeel wat Kotlin tegenover Java heeft is misschien een valse start, maar het is de reden dat Kotlin zo groot aan het worden is denk ik, en dat is de Java interoperability. Dit houdt in dat Kotlin vlekkeloos samen kan werken met Java in dezelfde codebase. Nog beter, wij kunnen Java-code aanroepen vanuit Kotlin en omgekeerd Kotlin code aanroepen vanuit Java. De compiler heeft hier geen problemen mee en zal zijn werk doen zoals altijd.

Het grote voordeel hieraan is dat Kotlin overal geadopteert kan worden waar Java wordt geschreven. Als een team niet comfortabel is met Kotlin kunnen zij kiezen om kleine stukken van de code te pakken en die om te schrijven naar Kotlin, om zo gaandeweg meer ervaring op te doen met Kotlin en comfortabeler te worden met de taal.

Voortbouwend hierop is dat de ontwikkelaars bij JetBrains er alles aan hebben gedaan om de conversie van Java naar Kotlin zo makkelijk mogelijk te maken. In hun IDE, IntelliJ, hebben zij de functionaliteit ingebouwd om Java-code in een Kotlin bestand te plakken (via copy-paste) om een popup te tonen die vraagt “Wil je deze code omzetten naar Kotlin?”. Als er akkoord wordt gegeven zal IntelliJ zelf de Java-code converteren naar Kotlin code dat in 99% van de gevallen klaar is voor productie. Dit kan een software engineer helpen om bekende Java-code automatisch te converteren en het resultaat te bestuderen om Kotlin beter te leren begrijpen. Er wordt immers vanuit een bekende basis gewerkt in dat geval.

Nu voor de echte start, en mijn persoonlijke favoriet: data classes. In Java bestaan de zogeheten POJO’s, of Plain Old Java Objects. Het zijn simpele objecten met een aantal velden, en methodes om de waardes van die velden op te halen of te veranderen. Een voorbeeld hiervan voor een boek klasse is als volgt:

public class Book {
     private String title;
     private String author;
     private int amountOfPages;
 
     public Book(
         String title,
         String author,
         int amountOfPages
     ) {
         this.title = title;
         this.author = author;
         this.amountOfPages = amountOfPages;
     }
 
     public String getTitle() {
         return this.title;
     }
 
     public String getAuthor() {
         return this.author;
     }
 
     public int getAmountOfPages() {
         return this.amountOfPages;
     }
 
     public void setTitle(String newTitle) {
         this.title = newTitle;
    }
 
     public void setAuthor(String newAuthor) {
         this.author = newAuthor;
     }
 
     public void setAmountOfPages(int newAmountOfPages) {
         this.amountOfPages = newAmountOfPages;
     }
 }

De bovenstaande klasse bestaat uit 38 regels code en is erg simpel. Er zijn drie velden, title, author, en amountOfPages, een enkele constructor, en de getters en setters. Kotlin kan dezelfde code genereren door een data class aan te maken. In het geval van een Book klasse gaat dit als volgt:

data class Book(
     val title: String,
     val author: String,
     val amountOfPages: Int
 )

Dat is alles! Vijf regels code en hetzelfde resultaat is bereikt als de 38 regels van Java code. De Kotlin code beschrijft een constructor tussen de gewone haakjes, en daarbinnen de drie datavelden die wij willen. De compiler zal begrijpen wat nodig is voor de data class en daarmee alle getters en setters genereren.

Het bestaan van de data class maakt het zoveel eenvoudiger om een POJO (of eigenlijk POKO in dit geval) te maken dat het erg aantrekkelijk is om “even gauw” een data class ergens voor aan te maken omdat dit simpelweg eenvoudiger is dan ingewikkeldere constructen zoals een tuple of pair.

De data class is niet de enige soort nieuwe klasse. Kotlin kent voor de visibility van classes naast de private, protected, en public types ook de types sealed en internal.

Een sealed class is een klasse of een interface waarbij alle subklassen en implementaties bekend moeten zijn tijdens het compileren van de code. Dit zorgt ervoor dat een derde partij niet nog een extra subklasse later toe kan voegen als er bijvoorbeeld een library geschreven is (de klasse is “sealed” voor verdere subklassen). Sealed classes hebben hun weg wel gevonden naar Java als een preview sinds Java 15, en als volwaardig onderdeel sinds Java 17. Echter, ze zijn langer aanwezig in Kotlin en hebben betere support. In Kotlin is het bijvoorbeeld mogelijk om een sealed class in een switch statement te gebruiken - Java staat dit als preview functie toe in Java 17, maar er is nog geen officiële support. Ook is Java stricter in het gebruik van sealed classes. De sealed class zelf moet expliciet aangeven welke subklassen toestemming hebben om een extension te maken via het keyword permits.

In mijn optiek zorgt dit voor meer verbose code en ligt mijn voorkeur bij de aanpak van Kotlin. Daarbij mag elke klasse een subklasse zijn, maar de subklassen moeten in dezelfde file als de sealed class staan. Een voorbeeld daarvan staat hieronder. Het werken met sealed classes vind ik zelf erg fijn in Kotlin doordat de code compact is, en ik weet dat ik klassen kan schrijven die alleen de subklassen heeft die ik wil, wanneer dan ook. Dit kan recente versies van Java inmiddels ook.

sealed interface Error
 
sealed class IOError(): Error
class CustomError(): Error

Een companion object is een manier in Kotlin om statische variabelen te maken die onderdeel zijn van een klasse, maar gebruikt kunnen worden zonder de klasse te instantiëren. Doorgaans gebruik ik een companion object zelf om statische variabelen aan een klasse toe te wijzen zoals normaal in Java gedaan zou worden. Dit gaat heel eenvoudig op de volgende manier:

class Coffee {
     companion object {
         const val optimalTemperatureInCelsius: Int = 140
     }
 }

Belangrijk hierbij is dat er een annotatie extra nodig is voor goede Java interoperability. Door @JvmStatic boven de companion object variabele te plaatsen kan dit bereikt worden. Dit is nodig omdat een companion object in Kotlin kan overerven van klassen of interfaces, maar in Java is dit niet mogelijk.

Er zijn nog andere manieren waarop nuttig gebruik gemaakt kan worden van een companion object. Een voorbeeld hiervan is het Factory design pattern. Door gebruik te maken van een named companion object kan een Factory heel eenvoudig opgezet worden:

class Coffee {
     companion object Brewer {
         fun brew(): Coffee = Coffee()
     }
 }

De factory is Brewer genoemd in dit voorbeeld, en de gebruikelijke createInstance is nu brew genoemd om in het thema van de klasse te blijven. Vervolgens kan de factory gebruikt worden op de volgende manier:

Ik vind persoonlijk null safety erg belangrijk in code, en ik ben erg blij met het type system in Kotlin. Het type system probeert namelijk om null referenties te voorkomen. Dit wordt gedaan door variabelen niet standaard een null mogelijkheid te geven, maar dit expliciet af te laten dwingen. Bijvoorbeeld, bij het aanmaken van een String moet de String een waarde toegewezen krijgen, anders compileert de code niet. Door gebruik te maken van een ? bij de variabele vertel je de compiler dat null toegewezen mag worden aan de variabele.

val someString: String = "Hello There" // mag geen null zijn
val anotherString: String? = null      // mag null zijn

Helaas zie ik in mijn dagelijks programmeerwerk een hoop mensen die denk ik uit gemak toch vaak met null willen werken. Ik zie dit als een soort “Java-isme” wat over is gekomen naar Kotlin. Hierdoor is de code al vrij snel bezaaid met ?s en de bijbehorende if-statements die op null controleren. Gelukkig is Kotlin hier op voorbereid en is er een shorthand voor de null checks in de vorm van, alweer, een vraagteken ?. Dit werkt als volgt:

Kotlin controleert hier of de waarde van anotherString null is of niet. Als er null geconstateerd wordt dan gebeurt er verder niks - de check heeft gefaald. Als er geen null wordt geconstateerd dan heeft anotherString dus een waarde gekregen. In dat geval voert Kotlin het let deel uit en wordt de waarde van anotherString geprint.

Een andere manier van nullable variabelen gebruiken is minder veilig dan de ?, maar kan soms zijn nut hebben. Het kan namelijk gebeuren dat Kotlin een variabele als een mogelijke null ziet, maar als software engineer is duidelijk in de code te zien dat dit nooit kan gebeuren. In zulke gevallen kan gebruik gemaakt worden van een dubbele bang (!!). Dit dwingt af dat de waarde van de variabele gebruikt wordt - ook als dit alsnog null zou zijn. Het gebruik van !! moet dan ook, vind ik, minimaal blijven en het liefste voorkomen worden. Helaas heeft het vele gebruik van nullable variabelen met ? als gevolg dat de code ook al snel bezaaid is met !!s, waardoor de null safety van Kotlin in mijn ogen onderuit wordt gehaald. Dit neemt alleen niet weg dat de null safety van Kotlin een welkome functionaliteit is die goed werkt.

Named arguments neem ik tegenwoordig dusdanig voor lief dat ik verbaast was toen ik (her)ontdekte dat Java deze feature niet ondersteunt. Het is een kleine toevoeging in de code, maar het maakt (in ieder geval voor mij) echt een wereld van verschil. Bij het gebruiken van een functie met argumenten kunnen de argumenten namelijk een toegewezen naam krijgen, zoals gedefinieerd in de functie zelf, maar nog belangrijker is dat ze ook een eigen plek toegewezen kunnen krijgen.

Normaal gezien zou een functie in Java gedefinieerd en gebruikt worden als volgt:

public static Coffee create(String name, int temperature, BeanType beanType) { ... }
 
Coffee.create("Cappucino", 95, BeanType.DARK_ROAST);

In bovenstaand voorbeeld is impliciet duidelijk waar de argumenten voor staan, maar om zeker te zijn moet toch naar de functie definitie gekeken worden. Dit kan nog omzeild worden door de argumenten eerst te definiëren:

String name = "Cappucino";
int temperatureInCelsius = 95;
BeanType beanType = BeanType.DARK_ROAST;
 
Coffee.create(name, temperatureInCelsius, beanType);

Echter, dit zorgt voor meer regels code en is een manier van werken die ik tegenwoordig niet mooi meer vind. De zojuist gegeven voorbeelden kunnen met behulp van named arguments in Kotlin geschreven worden op een mooiere manier.

class Coffee(name: String, temperature: Int, beanType: BeanType)
 
Coffee(name = "Cappucino", temperature = 95, beanType = BeanType.DARK_ROAST)

Nu is direct bij het aanmaken van een Coffee object te zien waar de argumenten voor staan. In dit geval staan de argumenten nog in dezelfde volgorde, maar stel dat we de argumenten in een andere volgorde willen, bijvoorbeeld om extra focus te leggen op het type boon. Dit kan eenvoudig opgelost worden door beanType naar voren te plaatsen. Of stel dat name een standaard waarde heeft die wij willen gebruiken. In dat geval slaan wij het hele argument simpelweg over.

// Andere volgorde
Coffee(beanType = BeanType.DARK_ROAST, temperature = 95, name = "Cappucino")
 
// Argument overslaan. Eerst wordt een klasse definieerd met een standaard waarde voor 'name'.
class Coffee(name: String = "Black", temperature: Int, beanType: BeanType)
 
Coffee(beanType = BeanType.DARK_ROAST, temperature = 95)

Als laatste functionaliteit wil ik de string templates van Kotlin in het licht zetten. Strings zijn in Java lastig om mee te werken, of in ieder geval om te manipuleren. In Kotlin kunnen argumenten direct in de String zelf worden geplaatst. Deze functionaliteit is ontzettend eenvoudig maar voegt zoveel plezier in het programmeren toe, simpelweg doordat een complexe String opbouwen zo makkelijk gaat.

Als voorbeeld, stel dat wij een rekensom uitgeprint willen hebben als String. Dit is in Kotlin direct uit te voeren:

val firstNumber = 25
val secondNumber = 5
 
println("First number is $firstNumber. Second number is $secondNumber.\n$firstNumber / $secondNumber = ${firstNumber / secondNumber}")

De argumenten kunnen direct in de String gebruikt worden door er een $ voor te plaatsen. Bij complexe onderdelen van de String kunnen simpele berekeningen gedaan worden door de berekening te plaatsen binnen haakjes {}. [String templates zijn in versie 19 ook aan Java toegevoegd - red.]

Ik hoop dat deze blogpost meer was dan een simpele vergelijking tussen Java en Kotlin. Kotlin is een programmeertaal die dagelijks het programmeren makkelijker en leuker maakt voor mij dankzij het gemak van de features die het heeft. Het voelt op zijn minst als een goede toevoeging aan het JVM-ecosysteem, en uiteindelijk als een oprechte opvolger voor Java. Als je Kotlin nog nooit hebt gebruikt, geef het een keer een kans!

De dagelijkse voordelen van Kotlin

Simpel, eenvoudig en snel. Je wil snel aan de slag en dat is wat je als frontend developer maar al te graag wil. Bij verschillende projecten heb ik al meegemaakt dat je meermaals (lang) bezig bent met het configureren van de build tool, zonder dat je ook maar toe komt aan een regel programmeren. Dat hoeft niet erg te zijn, maar er zijn leukere dingen om je mee bezig te houden. Vite stelt zich voor als de volgende generatie frontend tooling.

Vite heeft een ecosysteem neergezet waarbij je snel kan beginnen met het ontwikkelen van een project. Hierbij is het mogelijk om direct gebruik te maken van de populaire frameworks als React en Vue, maar ook vanilla JavaScript is een kwestie van je ogen dicht doen. Met zero configuration heb je snel een tooling gereed waarbij je gebruik kan maken van SASS, TypeScript of wat dan ook. 

Vite richt zich op snelheid en performance door de development ervaring te verbeteren. Zo maakt het niet uit hoe groot je applicatie is, de applicatie start altijd snel op. Hot Module Replacement (HMR) zit eveneens in de core configuratie. Hiermee wordt dus alleen herladen wat je op dat moment hebt aangepast. De laatste belangrijke pijler is het compileren/bundelen van JavaScript door middel van ESBuild, welke bekend staat als een van de snelste bundlers van dit moment.

Onder de motorkap maakt Vite gebruik van zowel ESbuild als Rollup. Een van de redenen om gebruik te maken van ESbuild is omdat deze slim overweg kan met dependencies. Doordat deze niet frequent veranderen hoeft deze niet bij elke build opnieuw gecontroleerd te worden. Rollup wordt gebruikt zonder dat je daarvoor iets extra’s hoeft in te stellen. Dat kan natuurlijk wel, net als een heleboel andere dingen.

Vite omschrijft zichzelf dus als de tool die gebruikt maakt van de nieuwe ontwikkelingen van het ecosysteem; de beschikbaarheid van native ES-modules in de browser en de opkomst van JavaScript tools die compilen tot native languages. 

Nu de theorie veel belovend klinkt ben ik benieuwd hoe dit in de praktijk zal uitpakken. Begin een Vite project met het volgende commando in de terminal:

Bij de eerste keer van dit commando krijg je de vraag om de laatste packages te installeren, waarna je het project van een naam en framework moet voorzien. 

npm create vite@latest
Need to install the following packages:
  create-vite@latest
Ok to proceed? (y) y
✔ Project name: … vite-cinq
✔ Select a framework: › react
✔ Select a variant: › react-ts

Scaffolding project in /Users/jeroen/Development/_temp/vite-cinq...

Done. Now run:

  cd vite-cinq
  npm install
  npm run dev

Na een npm install en npm run dev is mijn lokale omgeving tussen 350-500 ms opgestart. Dat is best snel en dat zonder enige configuratie. Om het wat spannender te maken heb ik het React TypeScript TodoMVC 2022 project uitgecheckt en in mijn Vite project geplaatst. De conclusie was al vrij snel dat ik tot hetzelfde resultaat kwam als bij de initiële setup. Ook de standaard beloofde Hot Module Replacement (HMR) deed wat het moest doen. Ik heb op geen enkel moment een harde refresh van de hele applicatie nodig gehad. 

Het bouwen van productiecode gaat even makkelijk als het starten in de development mode. Hoewel dit bij andere tooling ook wel te doen is, lijkt het voor mijn gevoel sneller te gaan. Een mooie toevoeging is dat je na het commando npm run build ook een commando npm run preview hebt om het eindresultaat snel te kunnen zien. Dat vind ik een leuk pluspunt.

Zo zijn er nog meer dingen die out of the box al standaard werken, bijvoorbeeld:

het toevoegen environment variables volgens de dotenv structuur; 

het gebruiken van CSS modules en/of CSS Pre-processors;

het instellen hoe je assets ingeladen moeten worden en;

het gebruiken van global en dynamic imports.

Of Vite de vervanger van Webpack gaat worden durf ik niet te zeggen. Net als met veel andere tools en frameworks gebeurt er veel onder de motorkap, waardoor je niet zelf inzicht hebt over hoe en wat er gebeurt. Je hebt alleen zicht op de input en de output. Bij Vite vind ik het verschil tussen development (esbuild) en productie (rollup) niet prettig.

Al met al krijg ik over Vite als tool een goede indruk, omdat het mij – na een paar uurtjes ermee spelen – een positieve vibe geeft aan de developer experience. Je krijgt veel out of the box om een snel een project te kunnen starten. Dit maakt het voor mij toegankelijk om hier bij een greenfield project voor te kiezen. Of je ook echt moet willen dat een tool je (snel) alles geeft betwijfel ik. Graag zou ik wat meer controle willen hebben.

Wordt ViteJS de opvolger van Webpack?

In this blog, I would like to share something I recently discovered when studying for the Java 11 certification. Strangely enough, it is not a new Java 11 feature. It’s not even something introduced in Java 8 or 7. No, it’s something that's been around since the early days of version 6. It’s the ServiceLoader class. A long-forgotten feature which thanks to the introduction of modules in Java 11 has become especially relevant again.

The ServiceLoader class was first introduced in Java 6. It was used to make applications extensible, so you could add functionality without recompiling the whole application. Basically, the SeviceLoader scans the classpath looking for an implementation of any interface you may want and returns the results, which then can be used at runtime in your code. Essentially, this is a form of dependency injection.

Dependency Injection
What is dependency injection and why is it important? Quality code should adhere to the following design principle:

This principle is not rocket science. It simply means that an object that uses another object should not create that object, but instead receive the objects it is dependent on. This technique is called dependency injection.   

There are many ways of injecting dependencies into objects. 

1 - You could use a framework. There are quite a few dependency injection frameworks Java developers can choose from. For example, Spring Framework or Google Guice are very popular. 

2 - However, a framework is not necessary. There are far simpler techniques for achieving the same goal. There are several methods of dependency injection in Java without the need of leveraging third party frameworks and only rely on simple regular everyday code. The simplest are: 

Constructor injection. The dependencies are injected via constructor parameters. 

Setter injection. After the object has been initialized, setter-methods are used to add the dependency. 

Factory method. Similar to the Constructor injection method, however, the constructor is called with the necessary parameters within a method belonging to a Factory class.  

Factory injection. This is an improvement to the Factory method. By implementing the Factory Pattern. Basically, all the logic needed to initialize the object with all the necessary dependencies are abstracted away within an independent class, a Factory class. This object internally decides which dependencies are needed. 

The main advantages of these methods are that you don’t need to add any external libraries to your build path, nor do you need to use any ‘funny looking’ annotations to tell the framework what needs to be injected and where. It is done in plain old, easy to understand Java code.  

3 - “But I need to dynamically switch between implementations in my code”, I hear you say. Yes, there are some use cases where you may need to load an implementation of a class at runtime. Luckily, that’s not a problem in Java. There is the ServiceLoader class. 

As previously discussed, this class has been around since version 6, and can be found in the java.util package. This class will scan through the classpath or (from version 11) through the module path of your application and retrieve the available implementations. Giving you a Java native way of dynamically loading classes and injecting them into objects. Most probably in conjunction with some kind of Factory class to abstract away some of the code.

Module path
Before we dive further into the workings of the ServiceLoader class, I need to discuss the new module system introduced in Java 11. 

In layman terms, in Java 11 the classpath has been replaced by a module path. Don’t panic, you can still use a classpath, but this is no longer advised. 

The biggest difference between a classpath and the newer module path is that when using a classpath Java searches through all the locations designated on the classpath looking for the class to use. Often, this works fine. However, it is possible to have multiple instances of the same class defined on your path. And because Java has no strict way of traversing through the classpath, your application will randomly use different implementations of a class. Potentially causing all kinds of unpredictable problems, colloquially called “Dependency Hell”.

This has been fixed in the module path way of working. Instead of an unorganized collection of available classes. Classes and packages are now ordered into neatly organized modules. And because modules need to declare which classes they make accessible for other modules and which modules they use; java has the ability to validate all modules loaded at compile time helping to prevent dependency hell. 

The ‘exports’ keyword is used for making packages available and the keyword ‘requires’ is used for declaring which modules are used. This information is placed in the module-info.java file, which can be found in the source folder.

ServiceLoader
As previously described, the ServiceLoader is able to search the classpath looking for implementations. But how does it work when using a module path? Modules no longer implicitly expose any classes. Therefore, an implementation (also called a Service in Java 11) needs to be exposed to the outside world. This is done by using the keywords ‘provides … with ...’. Also, you need to declare that a module uses an external implementation. This is done by using the ‘uses’ keyword.

Module 1 – The module exposing (exporting) the interface
Module definition

Module 2 – The module providing the service implementation (doesn't need to be exported!)
Module definition

 Module 3 – The module using the service: 
The module definition of a module using a service.

If all the modules have been correctly defined, then using the ServiceLoader is easy. You only really need to know one static method ‘load’ which takes a class as a parameter and returns a collection of Classes. Because the ServiceLoader can retrieve an unknown number of classes, you will have to write some code to determine which class instance (if any) to use.

Summary
To quickly summarize. In many cases of injecting dependencies, we don’t need a framework to get the job done. Java out-of-the-box offers us the tools needed to solve the problem of dependency injection.

In this blog, I would like to share a long-forgotten feature which has become especially relevant again, the ServiceLoader class

The ServiceLoader and Native Dependency Injection in Java 11

In this blog I want to give a short introduction into the use of monads in Java. Interestingly, the concept of a monad has been around for quite some time now. Originating in mathematics it’s a design pattern which has previously only been popular in functional programming languages. However, it has found its way to Java. There is even a large chance that you have already been using them unknowingly. Especially, if you have been using the Optional and Stream libraries introduced in Java 8. So, what is a monad and how does it help me write clearer code? 

The Problem
First, I’m going to start with the problem that a monad helps us to solve. Its main goal is to help abstract away boiler plate code that isn’t the main concern of your code. Think of null checking, exception handling, validation, logging, concurrency, etc. 

In this first code block, four classes have been declared. The first three classes represent a bank with customers which in turn may each have an active account. The Bank class has a single method which returns the Customer with the supplied id. The Customer class has a single method which returns the customer’s Account. The Account class also has a single method which returns the balance of the account. The final class ATM has a single method which takes a Bank instance and an id as a parameter and returns an account's balance.

The problem is that the methods in Bank, Customer and Account may return null. The id might not be correct, or the customer may no longer have an account at the bank, or the balance may not be available. This will result in the fetchBalance method of the ATM class throwing a NullPointerException, which will cause the program to crash.

We can fix this by refactoring the fetchBalance method to check if each value returned by Bank, Customer or Account happens to be a nullpointer (Alternative 1). We can all agree that this code works, but it’s not a pleasure to read. Alternatively, you could use nested if-statements to check for not null. However, this also has little effect on the readability of your code (Alternative 2).

 Another alternative (Alternative 3) would be to place the code in a ‘try-catch’. This would improve the readability, but hide the cause of the exception, limiting your ability to later add some code to be able to recover from the exception. 

What is a Monad?
 So, what is a monad and how can it help us write more readable code? A monad is defined as any class (data type), which represents a specific calculation. It must implement at least these two functions:

A function to wrap any basic value, creating a new monad. Also called the return function.

And a function that allows you to perform operations on a wrapped data type (monad). Also called the bind function.

It must also adhere to the following three monad laws:

Left identity, passing an operation to a monad should yield the same result as applying the operation to the original value.

Right identity, passing a wrapper function to a monad should yield the same result as creating a new nomad.

Associativity, when chaining functions, it should not matter how the functions are nested.

In this blog I want to give a short introduction into the use of monads in Java.

Onze laatste blogs over Development

How to write a simple IntelliJ plugin

Spring Batch to the rescue

Which tools do I use for improving front-end applications?

Bouke Nijhuis op Devoxx 2022 - Improving your skills with the debugger

De dagelijkse voordelen van Kotlin

Wordt ViteJS de opvolger van Webpack?

The ServiceLoader and Native Dependency Injection in Java 11

Monads in Java: a short introduction

Oh no! I am going functional style after all this time...

Four more tips to pass the Java SE 11 Developer exam

De CINQeria; een wereld van microservices en frontends