Kotlin vs Java: performance

How does Kotlin performance compare to Java’s?

One of the questions you’re bound to have when switching over to Kotlin is whether or not it is faster than Java.

While an application’s performance is highly dependent on its OS, runtime, and the actual code, in general Kotlin will perform very similarly to Java.

JetBrain’s kotlin compiler produces JVM bytecode.  While I’m not going to an analysis of the bytecode that it produces, from the research I’ve done it appears that it is very similar (at least in the performance sense) to the bytecode that Java compiles to.


While the question posed in this blog post is definitely a common one, it’s a bit too simplistic.  Much of how an app performs is dependent on the actual code that you write and the algorithms and data structures that you choose to use.

Kotlin has a distinct advantage over Java in this arena, because it provides us with implementations of certain programming patterns.  These patterns are highly efficient and likely to be less buggy than if you were to roll your own.

Take Kotlin Data Classes for example

You get this construct for free in Kotlin.  In order to do the same thing in Java, you have to write all the boilerplate code yourself.   This introduces the potential for that code to be buggy and inefficient.  Not good.

Joshua Bloch’s Effective Java describes the Immutable Object pattern.  Kotlin Data Classes are a great implementation of this pattern.  And you get it for free, built into the language.


Comparing Kotlin’s performance to Java’s is a common question that many have before switching from Java to Kotlin.  Kotlin compiles to JVM bytecode and the bytecode it produces is very similar to Java’s.  There is no reason that Kotlin should be slower than Java when comparing equivalent code.

Comparing speed of languages is less important than the data structures and algorithms used by the developer.  Kotlin provides some great built-in patterns that result in cleaner, easier to read, and less buggy code.

Introduction to Kotlin for Android


What is Kotlin?

Kotlin is a programming language that purports to be 100% interoperable with Java. Created by JetBrains — the company that created IntelliJ IDEA, WebStorm, and others. JetBrains released the first version in 2011, reportedly after one year of development. The 1.0 release of the language happened on February 15, 2016.

Kotlin is an Open Source language, developed on Github (https://github.com/JetBrains/kotlin) under the Apache 2.0 Open-source license. As of this post, there are 139 contributors to the project.

Why develop with Kotlin?

  • Safe — for example, null references are controlled by the type system
  • Concise — reduces a lot of boilerplate code
  • Versatile — build Android apps, front-end code, and server-side applications
  • Interoperable — with frameworks and libraries of the JVM
  • Easy to read and learn — less verbose than Java
  • Great tooling — Java-to-Kotlin converter, command-line compiler

Kotlin advantages and features

  • Lambda expressions
  • Extension functions
  • Null-safety
  • Smart casts
  • String templates
  • Properties
  • Primary constructors
  • First-class delegation
  • Type inference for variable and property types
  • Singletons
  • Declaration-site variance and Type projections
  • Range expressions
  • Operator overloading
  • Companion objects
  • Data classes
  • Separate interfaces for read-only and mutable collections

Projects that use Kotlin


Why is Kotlin good for Android development?

Oftentimes in Android you’ll get crashes due to NullPointerException. As null references are controlled by the type system in Kotlin, you are much less likely to come across them.

Less crashes == happier customers == better app ratings.

Jake Wharton has a post that describes some advantages Kotlin brings to the table for Android.


Kotlin is a great new language replacement for Java.  It’s very popular in the Android development community, and can be used for back-end server-side development, as well as front-end development.

Try it out for yourself with the online demo IDE: http://try.kotlinlang.org/

Spring Autowired annotation

In my previous post I briefly introduced the concept of Spring’s @Autowired annotation. This post goes more in-depth about this annotation, and its importance when developing with the Spring framework.

Spring uses the @Autowired annotation when it determines where it needs to inject a given @Bean. You can see this in the example below:

This example uses @Autowired on a private member variable referenced via class. In this example, the @Component is on the WeatherService class. The DependencyInjectionWithSpring class references the WeatherService class directly. I’ve annotated this reference with the @Autowired annotation. Spring then knows that it needs to find a bean (component) that matches. In this case, it finds the WeatherService class and injects it into the DependencyInjectionWithSpring class.

You can also reference with @Autowired via interface:

Here, I change the WeatherService class to be named WeatherServiceImpl, and have it implement the WeatherService interface, which I’ve also defined. DependencyInjectionWithSpring now references this interface (WeatherService), and the @Autowired annotation stays. Spring then knows that it needs to find a bean/component that implements the WeatherService interface. It finds the WeatherServiceImpl class and injects it into the DependencyInjectionWithSpring as a dependency (weatherService).

Field X in Y required a single bean, but 2 were found

What happens if we have multiple beans (components) that implement the same interface? Like this:

Both SunnyWeatherServiceImpl and CloudyWeatherServiceImpl implement the WeatherService interface. The DependencyInjectionWithSpring class depends on an implementation of WeatherService. Both of these classes would work, since they implement that interface. Spring is aware and manages both of these classes, since they are annotated with the @Component annotation. How does Spring know which one to choose? Let’s run the application and see what happens:

The application is unable to start. Spring can’t determine which bean to set for the weatherService.

How do I fix this?

To resolve this issue and tell Spring which bean to use in this situation, we have a few options.

The first option is to follow the first suggestion given in the exception:

Consider marking one of the beans as @Primary…

The @Primary annotation can be used to indicate to Spring which bean to use. In this case, I add the @Primary annotation to the SunnyWeatherServiceImpl:

Now when I run the application, it starts up with no errors and runs as expected, injecting the SunnyWeatherServiceImpl (the one with the @Primary annotation) into the DependencyInjectionWithSpring class.

There’s another option that Spring gives us, as mentioned in the error message from above:

or using @Qualifier to identify the bean that should be consumed

@Qualifier is a Spring annotation that allows us to tell Spring which bean we want to inject. See below:

Pay particular attention to the DependencyInjectionWithSpring class. The weatherService dependency in this class is now annotated with @Qualifier(value="cloudyWeatherServiceImpl"). This tells Spring to use the cloudyWeatherServiceImpl bean when injecting this dependency.

Now when I run the application, again it starts up with no errors and runs as expected. This time, I told Spring to use the cloudyWeatherServiceImpl class and it prints out The weather is cloudy with a 90% chance of rain as expected.

There’s yet another way to indicate to Spring which bean to inject. This is by naming the variable of the dependency the name of the class we want to inject. Like so:

Here, the WeatherService interface gets the name cloudyWeatherServiceImpl. This tells Spring that I want to inject the bean with the name cloudyWeatherServiceImpl. When I run this code, the application again starts up with no problems, and I again get the expected output.


Spring’s @Autowired annotation is used to indicate where to inject a Spring-managed bean. The @Primary annotation allows us to indicate which bean to use when multiple beans that match are present. The @Qualifier annotation allows us to specify a specific bean to inject on a given dependency. Finally, we learned that we can name the dependency with the bean name to also specify which bean to inject.

Dependency Injection using Spring

This post describes the basics of how to do dependency injection with the Spring framework. If you are unfamiliar with dependency injection, you may want to check out my first post on dependency injection before continuing.

Let’s start of with an example

Here we have two classes – DependencyInjectionWithSpring and WeatherService. WeatherService is a dependency of DependencyInjectionWithSpring. DependencyInjectionWithSpring instantiates WeatherService. Its run() method calls the printWeather() method on WeatherService. Pretty simple stuff.

Can you spot the problem? Take a minute and look at DependencyInjectionWithSpring. This class instantiates the WeatherService class, and sets this object to its private member variable weatherService. This is not a problem per se, or rather not compile time or even a runtime problem. This code still compiles. It still runs. It still produces the result we are trying to achieve.

I don’t see any problems with this, can you explain?

Here are a few

  1. Testability – you can’t test DependencyInjectionWithSpring without testing WeatherService as well. What if weather service gets its data from a thermometer or some external system? You wouldn’t want to wait for the service to run for your tests to complete, that could take a while. Unit tests should run fast. Also, you don’t have control over what WeatherService returns. Since you don’t have this control, how can you test for certain conditions, like returning null or throwing an exception.
  2. Reusability – as in the Testability problem, you can’t reuse DependencyInjectionWithSpring without getting WeatherService. This limits how and where we use this class, since wherever we have DependencyInjectionWithSpring we get WeatherService. What if we wanted different behavior than what WeatherService provides? We can’t in this case.
  3. No configuration without recompilation – what if we wanted to change the implementation of WeatherService? What if, instead of reading the weather from a thermometer we wanted to read it from a web service instead? In our current implementation, we are stuck. We would have to write code to change WeatherService to another implementation, recompile, and redeploy. As mentioned before, if we intend to use DependencyInjectionWithSpring we automatically get the WeatherService implementation with it. In other words, they are highly coupled.

So how does Spring help?

Here’s where the Spring framework can help us out.

The Spring framework is known as an IOC container. An IOC container serves two main purposes:

  1. Manage creation (and full lifecycle) of objects to be used in a system.
  2. Configure coupling of components. Spring provides (or injects) the objects it manages to the classes that depend on these objects.

For #1, that means we can get rid of the new WeatherService() piece. Like this:

If you try to run this, you’ll get a NullPointerException because weatherService has not been instantiated.

How does Spring fix this?

Since Spring is an IOC container it can instantiate objects on our behalf. The objects that get instantiated are known as Beans in the Spring framework. The way that you flag a class that you want Spring to be aware of (that is, you want it to be a Spring bean) is through the @Component annotation, like this:

This annotation lets Spring know that it should create and manage the lifecycle of this object.

However, if we run our code now, we’ll still run into a NullPointerException. Why is this so?

That’s where #2 from above comes into play. The Spring Framework also configures how components are coupled together. It injects objects into the classes that depend on them.


Spring injects objects via the @Autowired annotation. There are multiple ways that @Autowired can be used. To keep things simple, we’ll annotate a private member variable with @Autowired, and let Spring inject it for us. See below:

Pay particular attention to lines 23-24. This is where the WeatherService dependency gets injected into DependencyInjectionWithSpring.

Now, when we run it, we no longer see a NullPointerException, and the text The weather is sunny with a 20% chance of rain gets printed out, as expected.

To reiterate. Spring instantiates the weatherService for us. It also injects it where requested (via the @Autowired annotation).


If you notice in the gist above, and if you run the code, you’ll see that this application is not a web application, but a command line application. In particular, take a look at line 21 above implements CommandLineRunner. CommandLineRunner is an interface from Spring Boot that has one method with the following signature: public void run(String... args) throws Exception. In this example, our DependencyInjectionWithSpring class implements this interface, and in the run method calls the weatherService.printWeather() method.


In this post I described the basics of dependency injection with the Spring framework. Project examples can be found on my Spring Beginner Tutorial on github.

Getting Started with Spring (via Spring Boot)

How do I get started with Spring?

Software developers often ask me what the easiest way to get started with Spring is. There are, of course, multiple options for getting started. This post lays out a simple yet effective way to get started with Spring.

One of the best things to happen to Spring is a project called ‘Spring Boot’. In my opinion, this is the quickest and easiest way to get started with a Spring project.

Spring Boot

Spring Boot is a project from Pivotal Software that is designed to get you up and running fast. As the project website states, “Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can ‘just run’. We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration.”

Spring Initializr

What’s even more exciting about Spring Boot is the Spring Initializr site at start.spring.io This site will generate a Spring Boot project skeleton (choose either Gradle or Maven), let you set project metadata as well as which dependencies or Spring Boot Starters you want to include in your project. You then click the ‘Generate Project’ button to download a zip archive of your skeleton project. How cool is that??

There’s also a ‘full version’ from the same start.spring.io page if you want to choose options like Java Version, Language, and specific Spring Boot Starter dependencies.

OK, what’s the first step?

To get started, head over to start.spring.io From there, choose ‘Gradle Project’ and ‘Spring Boot 1.4.0’:

Spring Boot with Gradle

Or, if you’d prefer, you can get this project directly from my github repository – simply visit my Spring Beginner Tutorial repo where you can clone or download this Spring Boot project.

Specify Project Metadata:

Project Metadata

Under dependencies, just leave this blank for now.

Click Generate Project and download a zip of your project skeleton. Extract this into your project workspace and head over to Eclipse.

Generate Project

Open your project in Eclipse

From the Eclipse menu, choose File > Import > Gradle Project > Next

Specify the root directory of your project. Eclipse will then import your project.

Running a Spring Boot application

Now let’s go ahead and run our newly created Spring Boot application. Right-click on the project and choose ‘Debug As’ > ‘Java Application’. If, at this point, you get a dialog asking ‘Select Java Application’, go ahead and choose ‘ProjectNameApplication’, where ProjectName is the name you gave your project. Usually it’s the top option in the list.

In the console output, you’ll see several lines printed out. Once you see a line like the one below printed out, you know that your Spring Boot project is up and running:

INFO 10076 --- [ main] c.d.s.SpringBootIntroApplication : Started SpringBootIntroApplication in 2.833 seconds (JVM running for 3.426)

What does this project actually do?

If you followed my instructions exactly, you ended up with the basics of a Spring project, with a few essentials. Take a look at the debug output, in particular the following lines:

INFO 10076 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat initialized with port(s): 8080 (http)
INFO 10076 --- [ main] o.apache.catalina.core.StandardService : Starting service Tomcat
INFO 10076 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet Engine: Apache Tomcat/8.5.4
INFO 10076 --- [ost-startStop-1] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
INFO 10076 --- [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)

As you can see, the following gets launched as a part of running our Spring Boot application:

  1. Tomcat
  2. Spring WebApplicationContext

I’ll get into more details around the different context options in later blog posts. For now, just know that the Spring WebApplicationContext, along with the Tomcat Servlet Engine, are what allows your application to accept web requests. With your project still running, open up a web browser to http://localhost:8080 and see what response you get. You should see something similar to the following:


Don’t be alarmed with the 404 response, it’s actually expected. The 404 is actually coming from your Spring Boot application. A 404 is being returned because we still have more work to do. We need to map URLs to methods in our Spring Boot application to handle the request that come to the application. In future blog posts, I’ll get into those details.


Good job! You’ve now created your first Spring (via Spring Boot) application! It’s a simple application, but has all the pieces necessary for a Spring project. Spring Boot helped us along the way; it’s a great way to get a Spring project up and running.

Spring Beginner Tutorial: Dependency Injection Part 3 – DI without Spring

What is Dependency Injection? – Part 3

This is the third in a series of blog posts that I’m putting together for developers who are beginning to work with Spring. This post attempts to describe the basics of what dependency injection is.

Dependency injection is a fundamental part of Spring. It is so core to Spring that it warrants some explanation.

In the past couple of posts including this one I haven’t even shown a single line of ‘Spring’ code. Dependency injection, by itself, does not require Spring. In fact, there are many frameworks (outside and within Java) that use Dependency Injection. This is because DI is a design pattern. It’s a way to structure your code and manage your dependencies. It helps you control how classes interact with (and depend on) each other, both in production code as well as and especially in your test code.

Let’s start of with an example. You can follow along on my Spring Beginner Tutorial on github.

In the example below, ‘ExampleRunner’ depends on ‘InterfaceDependency’:

How does interfaceDependency get instantiated and set on ExampleRunner?

The simplest way that it could get instantiated and set is via the constructor of ExampleRunner. We could ‘new’ it up in the constructor of ExampleRunner, like so:

But this creates a problem. ExampleRunner is now coupled to a concrete implementation, InterfaceDependencyImpl, which is a concrete class (i.e. not an interface). This is a problem because every place ExampleRunner is used, it is always going to use InterfaceDependencyImpl. They are coupled together, inseparable, and there’s nothing a client of ExampleRunner can do about that.

Testing concerns

One place where coupling becomes a problem is when we want to unit test ExampleRunner. What if, for example, InterfaceDependencyImpl made a network call, or talked to a database, or performed some other long running operation. Now, anytime we run our unit tests against ExampleRunner we must wait for the network call to return (long and brittle), or depend on a database server to be running (unneeded dependency), or wait for some other process to finish. This is not good.

Dependency Injection to the rescue!

We can solve this problem with Dependency Injection (DI for short). DI follows the dependency inversion principle, which states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.

In our example above, ExampleRunner needs remove its dependency on InterfaceDependencyImpl. But how to we do that?

We do that by introducing the idea of an Injector.

An Injector is an object that coordinates dependencies. To keep things simple, the Injector in this example is the main method. Its job is to instantiate and set, or ‘inject’ dependencies.

Types of Injection

There are two different ways that dependencies are injected: Constructor Injection and Setter Injection.

Constructor Injection

The first method of injecting dependencies that I’ll describe is Constructor Injection. Take a look at the example below. This is code that exists in the Injector (main method in this example):

Here, we instantiate InterfaceDependencyImpl. We then pass it in as a constructor argument to ExampleRunner. The passing in as an argument to the constructor is the ‘injection’ part. This is Constructor Injection since the point we are injecting it into is the constructor.

If you run this code, you’ll see the following printed out:

Setter Injection

Setter injection is done via a method, typically a setter method. In the example below, InterfaceDependencyImpl is passed into ExampleRunner via the setDependency method. You may have noticed that I don’t pass in any arguments to the constructor in this example — the dependency gets set via the setter:

Constructor injection and Setter injection are the most common ways to inject dependencies. I personally prefer constructor injection for all dependencies, as I prefer to have all my dependencies in place before a class is used. For me, I like knowing that the class has everything it needs before it’s used. However, there are cases where setter injection is appropriate. For example, sometimes you can avoid circular dependencies if you set the problematic property via setter injection (though you should avoid circular dependencies where possible anyway). In my current project, I can’t think of a single place where we use setter injection, and it’s a good-sized project.

What were you saying about testing?

Back to the testing discussion. If you remember, I stated that when two classes are too tightly coupled, testing becomes more difficult (and sometimes impossible). Being able to specify the dependencies of a class helps in this regard. For example, if I am writing tests for ExampleRunner, and I need to simulate specific behavior of InterfaceDependencyImpl (for example, throw an exception), it becomes problematic if ExampleRunner itself instantiates InterfaceDependencyImpl. It’s a problem because ExampleRunner nor my unit test can control whether InterfaceDependencyImpl throws an exception or not. There’s no reliable way to simulate that. If ExampleRunner controls the instantiation and setting of this dependency, I have no choice but to test with that implementation. However, if I use DI to set my dependencies, I do have control of the dependencies of the class I’m testing. So, if I wanted to simulate an exception, I can create a test class InterfaceDependencyWithExceptionImpl, which throws an exception when invoked. I then inject this implementation for the interfaceDependency property (via either Setter or Constructor injection, it doesn’t matter). My test code can then focus on the behavior of the unit under test (ExampleRunner in this case), and how it reacts to scenarios like a dependency throwing an exception. This way I can set up my tests in a way that simulates a wider variety of scenarios.


Dependency Injection is fundamental to understand when learning Spring. Furthermore, it promotes good design by encouraging components to be loosely coupled. DI promotes separating the creation of a class’s dependencies from the behavior of those classes, and opens up numerous testing scenarios. In these examples I purposely left Spring out, as my intention here is to show you simple examples of Dependency Injection so that you’re not bogged down with syntax and Spring-specific details.

java.net.BindException: Address already in use:8080

Address already in use, BindException

If you’ve ever encountered this exception:
java.net.BindException: Address already in use:8080
there’s a great tool that you can use to determine what application(s) are running on a specific port: lsof

Looking at the man page for lsof, we find the following:

Lsof revision 4.81 lists on its standard output file information about files opened by processes for the following UNIX dialects:

AIX 5.3
FreeBSD 4.9 for x86-based systems
FreeBSD 7.0 and 8.0 for AMD64-based systems
Linux 2.1.72 and above for x86-based systems
Solaris 9 and 10

(See the DISTRIBUTION section of this manual page for information on how to obtain the latest lsof revision.)

An open file may be a regular file, a directory, a block special file, a character special file, an executing text reference, a library, a stream or a network file (Internet socket, NFS file or UNIX domain socket.) A specific file or all the files in a file system may be selected by path.

Instead of a formatted display, lsof will produce output that can be parsed by other programs. See the -F, option description, and the OUT-PUT FOR OTHER PROGRAMS section for more information.

In addition to producing a single output list, lsof will run in repeat mode. In repeat mode it will produce output, delay, then repeat the output operation until stopped with an interrupt or quit signal. See the +|-r [t[m<fmt>]] option description for more information.

To use it, type the following:
lsof -i:<port>
So in our case, we attempt to bind to port 8080, so running:
lsof -i:8080
Gives us an output like the following:

MyApp 50845 dustinkendall … … … … … …

To kill the process, type:
kill <pid>
So in our case:
kill 50845
This will help you get past the java.net.BindException and allow you to bind to that port.