Awareness of Kotlin drastically increased after Google I/O, but if you’re not developing on Android, why should you care?
Well, let me tell you. Kotlin is the Java we’ve been waiting for.
• Rely on your IDE to generate getters/setters/equals/hashCode?
• Use Lombok for defining data classes?
• Write lots of null check code, and lots of tests to verify null handling?
• Use annotations to verify null handling?
• Add external static analyzers for null verification?
• Leverage Optional (but only for return values, right?)
• Use Guava to provide a number of utilities?
• Use Apache commons libraries for many utility classes?
• Create utility classes that are effectively extensions for a Class?
• Create many overloaded functions in lieu of default parameters?
• Want to create DSL’s?
Then perhaps it’s time to switch to Kotlin. Yes, there’s some overhead in learning the language, and the compiler is a bit slower than Java’s, but given the items in the list above that need to be learned or known, and the extra processors for code generation and analysis, I think it’s a worthwhile transition, and ultimately isn’t any slower.
Data classes are built into the language. Getters, Setters, equals, hashCode and clone are all defined for it. Now when you’re reviewing code, you know immediately what’s defined for this class. No need to confirm that nothing is done in the setter/getter. No need to verify the implementation of equals/hashCode, or ensuring it has both.
If you use Lombok, you don’t have the above worries either, BUT you do require a plugin for your IDE, and additional build configuration to ensure the Lombok generator is executed.
Example data class that contains an immutable birthDate and mutable name property.
data class MyPojo(val birthDate: String, var name: String)
Null verification is built into the language. Just define the type, and it is non-null. To let the compiler know a variable is nullable, append a
? to the type. Very simple and readable.
The same applies to return values. No need to use a wrapper class (Optional) with all the new learning to use it property. (isPresent is not proper usage)
The compiler will verify via flow analysis, and unless you turn it off, verification will be performed at runtime.
No need to add annotations for non-null, or rely on conventions that all parameters are non-null. No need to wire in additional analysis/generation tools. No need to write code to verify parameters are non-null.
The standard library contains many extensions to common classes. Everything I’ve ever needed from commons-lang3 is in the Kotlin standard library. Guava Predicates is commonly used. Once again, this type of functionality is built into the Kotlin standard library.
And for comparison, Guava 22.0 is 2.6MB, while commons-lang3 3.6 is 495KB for a total of 3MB
while Kotlin stdlib is 881KB, stdlib-jdk8 is 12KB and stdlib-jdk7 is 3KB for a total of 896KB. Quite compact considering what it provides.
Kotlin provides extension functions so that you can provide additional methods on a Type whether it’s in your code base, or in a library. When writing code, extension functions look as if they’re defined on the Type (hence the name).
// Note, this already exists in stdlib
Hopefully you see that Kotlin encapsulates a number of best practices and standards directly into the language and compiler, rather than on external libraries and tools regularly applied doing Java coding.
And this is only the beginning of the features that Kotlin provides that make code easier to review, and reduce the chance of common errors creeping into the code.
I will create follow up posts to cover more features/benefits of Kotlin. Next will be static analysis.