Java To Kotlin Part 1: Java with Kotlin syntax

When learning a new language, even a new “framework” like Kotlin, one has to start somewhere. A familiar point of reference is always appreciated when trying something new.

Expected outcome of Part 1:
After reading and understanding part 1, you should be able to code Java with Kotlin syntax. It’ll be pretty crude, but it’s a good start. Should you be an IntelliJ user, the IDE will suggest additional ways to improve on any Kotlin code that you write.

Semicolons

The biggest difference you will notice between Kotlin and Java is that no semicolons are needed. They’re optional, and IntelliJ flags them as “redundant”. That said, if something does require multiple statements on one line, a semicolon is used to separate the statements. Most Java programmers will find themselves adding semicolons to Kotlin Code by pure reflex. It’s a habit that eventually disappears with time.

Classes

Class declaration is declared in the same way as Java:

The only exception is a constructor can be embedded into the class definition:

Empty constructors and class bodies are redundant and should not be included. The above is included purely as an example.

Parameters can be added to class constructors:

Variables are covered in a later section of this post.

Extending classes is fairly straightforward:

… Except that the above will not compile. Why? In Kotlin, Classes are considered final unless they possess the open modifier:

(Note the use of ("Samantha") when extending Employee. This is actually a call to the constructor of Employee)

Why is open needed? Kotlin follows the Effective Java guidelines and favours composition over inheritance. In this way, a developer must explicitly design a class to be extended. Should the class not be open, it’s treated as if the developer forbids the class from being extended See the chapter on “Favour composition over inheritance” chapter in Effective Java for more details.

A parent constructor can be called with parameters from the child:

class Developer(val EmployeeName: String) : Employee(EmployeeName)

This is a quick overview of declaring classes, intended to be a quick starting point to testing the next bits and pieces. More advanced class features will be covered in Part 2.

Methods

In Kotlin, methods are always fun. Literally. They start with fun (as in function):

Adding params to a method is largely the same as Java. The only difference is the name comes first, followed by the data type:

Furthermore, the final keyword is not needed, as that’s covered by val and var (covered below)

When returning values, the return type is placed at the end of the method declaration:

A more thorough overview of methods will be covered in part 2.

Variables

Kotlin prefers everything to be immutable. Everything can be considered final unless declared otherwise. In java, a variable would be declared using the final keyword. In Kotlin, all variables start with val or var. val is used for immutable (final) variables, while var is used for mutable variables. A rule of thumb is to declare all variables as val, then change them to var if they need to be mutated.

Variable Declaration:

The : String part isn’t needed when assigning a value to a variable (unless it’s nullable), so this can be shortened to:

The new keyword is not used for variable declaration in Kotlin as it’s considered boilerplate:

With parameters:

All of the above examples are not nullable, Kotlin views null almost as a different data type. A nullable variable contains an extra state (null) than that of a non-null variable of the same type. Attempting to assign a null to a non-null variable will result in a compile-time error (Or the IDE will show an error, if it is clever enough):

To make a variable nullable add ? to the end of their declared type:

An easy way to remember this is ? signifies that is possibly not a String value, as it might be null.

If we set myString to null, then attempt to read from it, there will be a compile error:

Assigning a nullable variable to a non-null variable is not possible:

This is because of type safety. Kotlin won’t risk potentially setting a non-null var to null. The var can always be null-checked first:

This works because Kotlin is smart enough to identify if a variable has been null-checked.

Be aware that the opposite is not true. You can assign a non-null var to a nullable var, as a nullable var can encompass all of the possible states of a nullable variable of the same type:

This is the the end of part one. Once the above is understood, you should be able to write basic Java with Kotlin syntax. It would be a good idea to play around with some code (and learn some techniques from the IDE) before moving onto part 2.

Examples for Part 1 can be found here.

Part 2 of the series can be found here.

Originally published at www.k0ma.co.za on October 15, 2018.